Open
Bug 269685
Opened 20 years ago
Updated 1 year ago
High CPU usage by extensions, no way to track down the extension responsible.
Categories
(Firefox :: General, enhancement)
Firefox
General
Tracking
()
NEW
People
(Reporter: resuna, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 StumbleUpon/1.999
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 StumbleUpon/1.999
Some extension sseem to be using busy-waiting in some of their background tasks,
at least there's times when Firefox hangs with 100% CPU usage, and sometimes
I've been able to associate these events with messages in the system logfiles
indicating there was an extension running. I've removed extensions when this
happens, or when I've had a hunch an extension was badly behaved, and Firefox is
a lot more stable, but it still happens occasionally.
What I want is a mechanism to track how much time Firefox is spending in
different extensions, so I can find out which, if any, if my remaining
extensions need to be ripped out.
Just having a file that it dumps when it enters and exits an extension and how
much CPU time it took that I could grovel through afterwards would be great.
Reproducible: Couldn't Reproduce
Steps to Reproduce:
If I could reproduce it I'd know what the problem was. :)
I'd describe this as a "critical enhancement". :)
Mac OS X 10.2.8 on G4/466
Comment 1•20 years ago
|
||
this is not possible, as it will probably have a signifant impact on
performance. This is backend, so moving to Browser.
Component: General → Browser-General
OS: MacOS X → All
Product: Firefox → Browser
Hardware: Macintosh → All
Version: unspecified → Trunk
Reporter | ||
Comment 2•20 years ago
|
||
I don't care what the mechanism is, the "file dump" idea was just a suggestion.
just dumping some kind of active extension info to stderr in a signal handler so
I can "kill -HUP $pid" and look at the console log would do.
Comment 3•20 years ago
|
||
> This is backend, so moving to Browser.
Actually, no. All the code related to extensions lives in toolkit/firefox...
Component: Browser-General → General
Product: Browser → Firefox
Reporter | ||
Comment 4•20 years ago
|
||
Still working on tracking down the problems. Removing extensions that edit the
page on the fly has been a big help. More recently, adding one extension has
reduced the number of uncontrolled CPU excursions significantly. That's
Flashblock: either there's a problem with the flash plugin or the way Firefox
uses it. I'll file another report on that if there isn't one.
I'm still getting some I can't account for, and I don't get them on an
extension-free profile. More diagnostics would really help.
Comment 5•19 years ago
|
||
I'd strongly suggest this, too.
Something like an in-Firefox [Windows] Task Manager equivalent.
When my system lags, I open Task Manager and kill it. (Most often, it is Firefox
or Thunderbird, in this order.)
And I really would be curious, which sub-part (e.g. Extension, Plugin) of
Firefox it is.
(In reply to comment #1)
> this is not possible, as it will probably have a signifant impact on
> performance. This is backend, so moving to Browser.
If so, then it should be default off. It could even be implemented as an
extension. But *when* Firefox tends to go 100&% CPU, I would happily spare the
CPU time for this tool, to spot out the real bad guy. And maybe deactive the
"Firefox Thread Manager" again, afterwards.
Btw, I also had most problems like this with Shockwave Flashes, but also a Java
applet. Both not 100% reproducible, meaning that it will reoccur often, but not
*always*.
Updated•19 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•18 years ago
|
Assignee: bross2 → nobody
Updated•16 years ago
|
Depends on: aboutmemory
I've tried all different versions of Firefox,
creating new profiles, selective disabling
of Add-Ons, just about everything I can find
on the Net.
A few months ago, Firefox would just become
unusable, even after rebooting, etc.
The current version I was using is 3.6.27
for Windows XP.
Add-Ons:
1. Tab Mix Plus 0.3.8.7
2. NoScript 2.3.5
3. AdBlock Plus 2.0.3
4. Element Hiding Helper for
AdBlock Plus 1.1.4
5. BlockSite 0.7.1.1
6. WOT 20120302
7. CopyAllURLs 0.9.2
8. OpenBook 2.0.1.1
9. XMarks 4.0.6
10. AVG Safe Search 10.0.0.1374
I've spent tens of hours trying to get
Firefox to work. I am now using Opera.
What is *ABSOLUTELY* needed is a way to
see how much CPU an extension is using
in real-time.
I sure hope someone will take a look at
this. I would if I had the time.
Is there a possibility that functionality like this might be implemented somewhere in the future ? A simple (?) way to find out which extensions / javascript functions are consuming CPU cycles would do the trick (IMHO), especially if these could be linked to the extension they belong to.
I can understand it may not be simple to implement this efficiently, but IMHO, even a less efficient implementation that can be switched on during a short interval when needed, would be perfectly fine for most people and purposes, as long as the performance impact is neglegible when switched off.
Please (re)consider implementing this sorely needed feature.
Note that it would (obviously) be very helpful to have this kind of CPU usage information available per open tab (i.e. per web page).
Comment 9•10 years ago
|
||
Comment 10•8 years ago
|
||
Possible workaround: 'Performance Reporter' add-on
"Displays extensions and tabs CPU and memory usage"
URL: https://addons.mozilla.org/en-US/firefox/addon/performance-reporter/
It works on Firefox release since version 47.
Updated•2 years ago
|
Severity: normal → S3
Comment 11•1 years ago
|
||
I believe this should be moved to the Performance Monitoring
component.
Flags: needinfo?(bugmail)
Updated•1 year ago
|
Flags: needinfo?(bugmail)
Reporter | ||
Comment 12•1 year ago
|
||
The situation has improved since I reported it, but that may simply be because I'm not running it on a 350 MHz G3 any more. :)
This ticket is old enough to drink in Australia.
You need to log in
before you can comment on or make changes to this bug.
Description
•