That isn't currently a target area for FHR. Things pertaining to the performance of particular webpages and such are extremely difficult to tease out of the data in a meaningful way. Not to say we will never include something like that in FHR, just not in the first couple of revisions of it.
Have you tried out the about:memory page? It doesn't do CPU, but it is a good way to see what particular pages are hogging memory.
Is it that Chrome is able to do it just because it's a separate process per tab? (It shows memory consumption by each page.) I try to go to the about:memory page every once in a while, but first that doesn't show information in a very intuitive way, and second, NONE OF the 'GC', 'CC', or the 'Minimize Memory Usage' buttons seem to reduce Firefox's memory usage. Sometimes pressing these buttons actually increases the RAM usage (as seen from the Task Manager on Windows) - which is beyond my understanding. The only way to reclaim the 2 GB of my system RAM firefox has captured is to restart it.
The garbage collector and cycle collector are run all the time normally, so clicking on those buttons shouldn't have too much effect on memory when you are using the browser normally. They are mostly useful for getting to a settled memory state right after opening a page rather than having to wait a few minutes for it to naturally happen, or in the rare cases where a GC should be triggered but isn't.
As for why running the GC might increase RAM usage, I guess it is possible that some memory had been paged out, but running the GC causes the browser to touch all memory, paging it back in. That's just a guess though.
> Things pertaining to the performance of particular webpages and such are extremely difficult to tease out of the data in a meaningful way.
It seems to me that you could do this "well enough" if you put each page in its own process and let the OS tell you which are burning the CPU. There could/would be edge-cases where a page causing issues would not appear like it was causing issues, looking at it from that level, but it would sure as hell be a good start.
I hadn't tried it before. It's interesting and I can see it being helpful in some cases, but it's not immediately easy to parse. I'll probably have to spend some more time with it.
Comments
That isn't currently a target area for FHR. Things pertaining to the performance of particular webpages and such are extremely difficult to tease out of the data in a meaningful way. Not to say we will never include something like that in FHR, just not in the first couple of revisions of it.
Have you tried out the about:memory page? It doesn't do CPU, but it is a good way to see what particular pages are hogging memory.
Is it that Chrome is able to do it just because it's a separate process per tab? (It shows memory consumption by each page.) I try to go to the about:memory page every once in a while, but first that doesn't show information in a very intuitive way, and second, NONE OF the 'GC', 'CC', or the 'Minimize Memory Usage' buttons seem to reduce Firefox's memory usage. Sometimes pressing these buttons actually increases the RAM usage (as seen from the Task Manager on Windows) - which is beyond my understanding. The only way to reclaim the 2 GB of my system RAM firefox has captured is to restart it.
The garbage collector and cycle collector are run all the time normally, so clicking on those buttons shouldn't have too much effect on memory when you are using the browser normally. They are mostly useful for getting to a settled memory state right after opening a page rather than having to wait a few minutes for it to naturally happen, or in the rare cases where a GC should be triggered but isn't.
As for why running the GC might increase RAM usage, I guess it is possible that some memory had been paged out, but running the GC causes the browser to touch all memory, paging it back in. That's just a guess though.
> Things pertaining to the performance of particular webpages and such are extremely difficult to tease out of the data in a meaningful way.
It seems to me that you could do this "well enough" if you put each page in its own process and let the OS tell you which are burning the CPU. There could/would be edge-cases where a page causing issues would not appear like it was causing issues, looking at it from that level, but it would sure as hell be a good start.
I hadn't tried it before. It's interesting and I can see it being helpful in some cases, but it's not immediately easy to parse. I'll probably have to spend some more time with it.