Per tab CPU usage

[Octopuss]

Is there any way to tell how much CPU is each tab using?

[Moonchild]

Search is your friend.
Short answer: no.

[kilroi]

The problem: some open tabs and palemoon process is the cpu hog.
However its not palemoon but likely some ill javascript in one of the tabs stealing the cpu resources.
Is it possible to stop javascript by tab?

[vannilla]

The problem: some open tabs and palemoon process is the cpu hog.
However its not palemoon but likely some ill javascript in one of the tabs stealing the cpu resources.
Is it possible to stop javascript by tab?

Try something like uMatrix.
Search the forum for instructions on installing the last compatible version.

[kilroi]

Thank you, I was also looking for such soft for other reasons. Well I have nothing to hide, but ...

[sangheeta]

Search is your friend.
Short answer: no.

And with

Code: Select all

about:performance

?
There are some cpu % usage there.

[Moonchild]

Keep the age of my response in mind.
Before August 2018, we were on Tycho, where about:performance didn't exist.

On UXP, we indeed have about:performance, but please understand that that page is a hell of a lot of guesswork, not in the least because certain resources are shared between tabs. Its usability is limited but it can be used as an aid to guess which page or extension is being too CPU/resource hungry. Never more than an educated guess, though.

[sangheeta]

Keep the age of my response in mind.
Before August 2018, we were on Tycho, where about:performance didn't exist.

You're right, my mistake, didn't see post date.

[mrnhmath]

Keep the age of my response in mind.
Before August 2018, we were on Tycho, where about:performance didn't exist.

On UXP, we indeed have about:performance, but please understand that that page is a hell of a lot of guesswork, not in the least because certain resources are shared between tabs. Its usability is limited but it can be used as an aid to guess which page or extension is being too CPU/resource hungry. Never more than an educated guess, though.

Shouldn't it be removed? Not only because it's imprecise but its related components add "non-trivial" overhead to the JavaScript engine. Related Bugzilla entries are 1309946, 1406872 and 1498195

[New Tobin Paradigm]

Is it adding overhead when not loaded? As for should it be removed? Likely but maybe not.. I think while it is loaded the overhead of its self may make it less useful. So I dunno.

[mrnhmath]

Is it adding overhead when not loaded? As for should it be removed? Likely but maybe not.. I think while it is loaded the overhead of its self may make it less useful. So I dunno.

It sounds like it.

[Moonchild]

Actually, the overhead is called non-trivial but that is just best guess. It's a simple stopwatch and that doesn't take much in terms of processing.

Some relevant quotes from the people who designed this:

<Yoric> It should not take any visible time when about:performance is closed.

the main reason for which I had to come up with the Stopwatch, rather than reusing the profiler API, was that, after having discussed it with BenWa, we concluded that the profiler API was too heavy-handed/expensive for the task. I do not remember the exact criteria, but the profiler API wakes up the entire process once per ms (even if the process is paged out, if my memory serves), which is pretty bad, battery-wise and possibly CPU-wise. Also, I seem to remember that it uses lots of memory.

When its performance impact was questioned:

Before I landed this code, ~18 months ago, I spent several days profiling it on every site that I could think of (I'm almost sure that GSuite was included) and AutoStopwatch didn't show up. Nor did it show up on Talos, Arewefastyet, etc.

So I'm pretty confident the overhead this adds is minimal and won't have any real-world impact.

[New Tobin Paradigm]

The real question is.. Is any of this useful to anyone? Or rather, is it useful enough to anyone to keep?

[Moonchild]

The fact this thread exists is an indicator that at least some people find it useful...

[vannilla]

You could also try placing some giant header in about:performance saying something along the lines of "this feature is deprecated and will be removed in a future version", without touching anything else.
If someone complains you "undeprecate" it (basically just remove the header), otherwise, if no one says anything in a year or two (or twenty, paraphrasing a certain famous software), you remove the stopwatch.
Of course assuming you decide to remove it in the first place.

[Moonchild]

I'm pretty confident the overhead this adds is minimal and won't have any real-world impact.

[Moonchild]

If people think it needs some actual measurements, I can add a preference to control this performance measuring code, so people can test the difference with it on or off. Tit for tat, though, if I put time into adding the pref, I do expect people to follow-up with actual quantifiable measuring experiments to see if there is a significant overhead or not.