Closed Bug 67409 Opened 24 years ago Closed 23 years ago

Doing nothing has CPU Monitor at 75%

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Platform:
PowerPC
macOS
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: mikepinkerton, Assigned: sfraser_bugs)

References

Details

(Keywords: perf, Whiteboard: [OSX+] [@risk] [ETA 09.26] [PDT+])

Attachments

(3 files)

api to get num idle connections on an nsIMsgIncomingServer
3.96 KB, patch
Details | Diff | Splinter Review
access from the mail session, and support for news
8.49 KB, patch
Details | Diff | Splinter Review
nsMacMessagePump fix
1.60 KB, patch
sdagley
: review+
kinmoz
: superreview+
Details | Diff | Splinter Review
On macOSX's CPUMonitor, just sitting on a static page (not typing, no network access) has the cpu at 75% (500 MHz G4). Typing pegs the CPU. Should we try the Carbon event model? Anyone?
according to some reliable sources, this is caused by us calling WNE with a sleep value of 0 and polling while idle. We should replace calls to DoIdle, DoIdlers, and DoRepeaters with Carbon Timers and rewrite nsTimer to be a wrapper around carbon timers. I'm not sure if it's totally enough to just do the timers and not completely move to the carbon event model, but rumor has it that if we did, cpu would be back to 0% during idle. cc'ing some more mac folks
Keywords: nsmac1, perf
We tweak the sleep time for WNE so that we don't always call with 0 when not doing anything. Unless that code is broken...
*** Bug 73649 has been marked as a duplicate of this bug. ***
*** Bug 74942 has been marked as a duplicate of this bug. ***
This really needs to be addressed by going to UNIX NSPR and Carbon events.
Target Milestone: --- → mozilla1.0
this appears fixed in the 5/9/01 fizzilla build.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
This has not been fixed. Start up Fizzilla 5/9 build, then type www.mozilla.org into the URL bar. The meter sticks at 100% for the rest of the session (Mac OS X 10.0.3).
Well, fixed if you consider 5-10% constant CPU usage to be "fixed". Even OmniWeb and iCab use practically zero CPU when idle in the background. Typing in Mozilla is still really slow, and as I type this, it's several seconds lagged and using 30+% of the CPU. Or is that a different problem? Actually, I'm certain this isn't fixed. Mozilla was just sitting here doing _nothing_ (no typing, or anything) and was still eating over 33% of the CPU.
33% is better than 75% :) But I believe you that it's still not fixed. There is another bug on typing causing lots of CPU usage.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
When you type a URL into the URL bar, CPU usage shoots up to 100% and stays there. Should that be filed as a separate bug? Is it covered under this bug? By one of the other bugs relating to typing and CPU usage?
High CPU usage when typing is bug 58148.
Whiteboard: OSX+
On my setup (Mac OS 10.0.3) the 5/30 Fizzilla uses 100% all the time. I also filed bug 80816 about typing in the URL bar.
In the latest 5/30 Carbon build, my MacOS X machine seems to have the idle CPU utilisation fixed. I've just browsed a few sites through my modem, and while processor usage is consistently high at 90-100% while a page is loading, it is dropping back to a normal idle level when page loading is completed. Omniweb returns more idle time back to the system during page loading, but this might be due to differences in the application's internal design. There are clearly improvements still to be made in Mozilla, but overall the responsiveness of the complete system seems much improved in the latest build.
On my setup (OS 10.0.3 with Fizzilla 5/30) CPU monitor sticks at 100% when Mozilla is idle, then *drops* slightly when I click on a menu or while a page is loading. When the page finishes loading, the CPU monitor goes back to 100% and stays there.
Using Fizzilla 5/30, OSX 10.0.3, B&W G3 300, the CPU usage is initially ok. Its at 100% when a page is loading, then goes down to 4 to 9% according to top. But after surfing a while, something breaks and it goes into CPU hog mode. Even closing the main window it still stays at 100%. I havent discovered anything specific yet that puts it into whole hog mode.
someone just commented to me in email about leaving the 5/30 build running for 15-20 minutes just sitting there and when he came back to it, it was pegging the cpu and didn't stop, even when he quit and relaunched. i've noticed that something happens on my machine to where i have to log out/back in to avoid new window times taking > 10 seconds. i can't tell what triggers it, perhaps a force-quit or the pro7 debugger perhaps. i'm pretty sure it's not anything i'm doing because i backed out any of my changes and it still does it. something is very strange with the latest bits. i wonder if it's the recent NSPR changes.
Fizzilla 5/30 has cpu use pegged for me right now, so I decided to try Apple's "Sampler" and see how it works. I selected Attach and picked the appropriate LaunchCFMApp, sampling at regular intervals (20 msec). Then I clicked the Start Sampling button and let it capture 30 seconds worth and clicked Stop. All 1252 samples had DoMessagePump in the call stack. One level below had 1202 cases of nsMacMessagePump::GetEvent and 49 cases of nsMacMessagePump::DispatchEvent (mostly DoIdlers and DoRepeaters). The GetEvent cases had 1190 calls to _EventAvail and the call stack below that had up to 10 call levels. Could be EventAvail is expensive on OSX. You guys should try it - might make a lot more sense to someone who knows what the code is doing.
Yeah, we're getting stuck in a state where we think the socket or file transports are active (probably the file transport). My guess is that we have some kind of memory leak somwhere relating to the animated GIF throbber, which keeps the file transport active when it should not be. This might be an XP bug.
So here's another reason why using lots of CPU is really bad. If you're running on a laptop with battery, using lots of CPU drains the batter really fast.
I'd like to see this bug given higher priority. It is the highest-voted Mac OS X-only bug, and in my opinion the most serious problem with Fizzilla (Fizzilla is the only Mac OS X application that makes my PowerBook's fan kick in). What do you think?
I'm hoping the fix for bug 87861 fill fix this.
Depends on: 87861
What a funny thing. Right now i am using .9.2 (0 build id no optimized) and the only time mozilla's cpu usage drops below 50% (checking with top) is when I click on any menu options (click on file and let the menu window drop down). Then mozilla down to 0%. Other wise it is in the 70% range even with nothing open.
I concur with mozilla.org@pidgin.org's 2001-05-10 comments about the URL bar and CPU time in Fizzilla. I can reproduce the problem in the latest build by performing the following: 1. Start with OS X at a relatively idle state. Classic is running in the background, but it is sleeping. Nothing CPU intensive is running. 2. Launch Mozilla. (When Mozilla launches, after it initializes, it doesn't consume more than 1-2% CPU time on my Mac.) 3. Open a new window, if a window wasn't opened at startup. (If it helps, I'm using the classic theme.) 4. Click anywhere inside the text input part of the URL text box (where the cursor becomes an I-beam). 5. Press any alphanumeric key on the keyboard. Suddenly, Fizzilla's CPU usage rockets from 1-2% to 75+% of CPU time. Putting Fizzilla in the background does not cure this; the only way I've found to return Fizzilla's state to "normal" is to quit and relaunch. I'm not sure what the relationship is between this and bug 58148, if any. That bug seems to be more about filling out forms, though. This is with Fizzilla version 0.9.1, the most recent build as of this writing, running on top of Mac OS X 10.0.4 on a Power Mac G3 400MHz.
I should own this bug.
Assignee: beard → sfraser
Status: REOPENED → NEW
*** Bug 89311 has been marked as a duplicate of this bug. ***
*** Bug 89392 has been marked as a duplicate of this bug. ***
This is looking good so far on my commercial branch build. I'll leave it overnight and see what ProcessViewer reports in the morning. Right now we're bouncing between .5 to 5% of CPU and 8.1% of memory on my system with a tinderbox page up (animated images are set to animate once).
I'm running the 2001070318 Fizilla build on OSX 10.0.4, and it is using 100% CPU from the nstant I start it up. (I load the about:mozilla page at startup so this is before any network activity)
Another side note to my above comment. When in mail, if I am dragging a message to a new folder, the CPU usage drops to near 0% *during* the drap operation, then jumps back up top 100% when I release the mouse button.
*** Bug 89180 has been marked as a duplicate of this bug. ***
The fix in bug 87861 when into the trunk on 6/28, and the branch on 7/5, so, if this is a branch fizilla build, it won't contain the fix yet. Is it?
This seems to be partly fixed with 2001070912--CPU usage is lower overall. However, when I check an IMAP mail account, CPU spikes to 100% and stays there for the remainder of the session.
Like mozilla.org@pidgin.org, I'm seeing lower CPU usage overall in branch build 2001070912, but it spikes (and stays spiked) while reading newsgroups.
Mailnews is keeping IMAP and NNTP connections open for long periods, even after you close the mail window, which makes us think that we're "busy". Mailnews guys cced for comment.
It's not that we keep the connections open, is it? It seems more likely that it's because we keep a thread idle for each cached imap connection (but not for news). That thread sleeps for static const PRInt32 kImapSleepTime = 1000000; and then wakes up to check if the connection has any pending requests.
What the mac event loop code uses to determine "business" is how many socket transports are active, and both IMAP and NNTP seem to keep ahold of active transports for long periods. It sounds like there is a more involved test that I need to make, but I'm not sure how I'd do that. I want to get a feel for "active" connections.
I think the IMAP code is using the wrong units for its sleep time on Mac. You pass kImapSleepTime = 1000000 as the PR_Wait() timeout, which, on Mac, is 1000 seconds. You need to convert kImapSleepTime to the appropriate platform-specific PRIntervalTime units, using PR_MillisecondsToInterval() or PR_MicrosecondsToInterval(). I just filed bug 90079 on this.
Depends on: 90079
No longer depends on: 90079
> What the mac event loop code uses to determine "business" is how many socket > transports are active, and both IMAP and NNTP seem to keep ahold of active > transports for long periods. What do you mean by the mac event loop code? top is showing cpu usage at ~75%. Are you saying that top is basing this number on socket transports? Sounds fishy to me...
we keep nntp sockets for three minutes, and IMAP for 29 minutes, which is what we're supposed to do, and I don't think we're going to be changing that - it's true that we don't clean up the sockets if nothing happens with imap or news, but it seems to me that we need to have some way of marking a socket idle or something for the mac.
No. You need to need to move to Carbon Events if you want Mozilla/Netscape to ever be efficient on Mac OS X. There is no way around it. I realize that this may be a lot of Mac speficic code to change. But it needs to be done at some point. Of course it is a question of how far back Carbon Events have been implemented. But I think it works at least back to 8.6
The problem is polling for network data. Does Carbon Events have a way to force an event on incoming network data? What if you use a sleep of 0 only if you received any network traffic during this pass. If you are "busy" but didnt get any net traffic, use sleep of 1. It would introduce a little delay, but the sleep of 1 helps a lot.
The problem is polling for network data? In that event CE won't help. But in any event polling for network data should not take a lot of cpu for an idle one window instance of mozilla. I assumed that they are running the event loop too much. And CE will help out ther by calling back instead when there is something to do. However CE might help by instead of running the WNE loop all the time. You could install a timer that only do that. Minimizing the code run for each loop.
*** Bug 91322 has been marked as a duplicate of this bug. ***
I agree, we should be using Carbon timers for this polling, rather than relying on the event loop to turn the crank.
Any chance the IMAP issue will be (or can be) targeted for 0.9.4?
we're not planning on changing the imap threading model any time soon.
bienvenu: can you suggest a means to tell if the IMAP (and other mail/news sockets) are really busy?
On a per connection basis, we know internally if the connection is busy or not but you don't have access to that information. What exactly do you need to know? Whether there are any active connections? How many there are? Which open sockets are not active? We can figure any or all of that out but we'd need to add a new interface or two...What happens if we say they're not active, but then in the next millisecond they become active (e.g., biff fires, or the user clicks on a message?)
The information I want is some measure of whether the app is "busy" now. "Busy" means that we're getting data from the network, rendering a page etc, and it's used to tune the amount of time we yield to other applications (recall that Mac has cooperative multitasking). So what I need to know is how many of the sockets the mail is holding open are "active" (i.e. in the process of sending or receiving data). I don't think it will be necessary to anticipate activity; even when idle, we'll come round again in a few 1/10 of a sec.
It might be easier for us to tell you how many sockets are not active, since we don't have an easy way to calculate how many pop or smtp sockets are active, but we can easily tell how many news or imap sockets are idle. Would that work?
That would work, as long as I can tally those up with the total number of sockets in use according to the socket transport service.
*** Bug 93568 has been marked as a duplicate of this bug. ***
*** Bug 94399 has been marked as a duplicate of this bug. ***
The following Apple tech note may be helpful in resolving this bug, as well as giving Fizzilla better OS X performance. http://developer.apple.com/technotes/tn/tn2028.html - Adam
I just noticed that in NS6.1 PR for OS X - re:0.9.2, if I open NS6, I peg the CPU monitor - however, if I open a menu, the CPU drops to 0% ... releasing the menu and going back to doing things in NS6 seems to make CPU usage behave more normally. When I'm not typing - I see a tiny sliver of CPU usage, but nowhere near even 10%. Now when NS6 sits idle, it doesn't chew up the CPU! -Brice
Brice, There exists in fizilla a "stable" state, where the app knows it is not waiting for immediate data, and in that state, it uses very little CPU. That is the state you've reported. However, there are many other states where it thinks there is immediate data forthcoming, when there is not. These are the states which are problematic. The easiest way to get into that state is to open mail/news, and access any kind of mail/news server (i.e. nntp, I think also pop/imap servers also cause this). Then, as far as I can tell, the only way to get the CPU usage down is to restart mozilla. Personally, this means that I don't use mozilla for mail (I might if not for this issue), and I make an "appointment" to use it for news: I make sure I don't have any important browser windows open, then I read my news and restart mozilla. Since I'm usually using this on a notebook, (tiPB), It's just not practical to leave it in this spin-loop state, where it cranks the fan on, the case gets too hot to leave on the lap, and the batteries drain like they're powering an electric heater (they are). All: Is mozilla1.0 really the earliest target for at least attempting to work on this with the current framework? I'd suspect that a 1.0 timeframe for moving to Carbon Events might be reasonable, but I'd also suspect that that might still get pushed back because it's a lot of work. Could the solution that sfraser and bienvenu were talking about be implemented sooner? Heck, i'd be happy with a way to just manually subtract 1 from this counter when I _know_ it's spinning uselessly. Or maybe just some kind of back-off that says that if data hasn't been recieved in some period of time, to start inserting some time into the spin-loop to bring this back under control. Don't mean to be a pest, as I can't help do the work right now (need to scrape up a copy of CW5, I guess), but maybe this note can clear things up for others?
A quick follow up to Steve K. When Mozilla hits this endless cycle or looking for data a simple fix does exist... other than a closing down the app. Just go offline (just use the little plug at the bottom of every browser window). Everything backs down near 3%-5% then go back online and presto it is just like Mozilla restarted. (But make sure mozilla drops to an acceptable cpu usage before going back online. Sometimes this 'method' takes about a min to work on a 733G4)
Keywords: nsenterprise+
Priority: -- → P2
Target Milestone: mozilla1.0 → mozilla0.9.5
bienvenu: any progress on the mail APIs which would allow me to query about active mail/news connections?
can we get an update of where we are on this? Is this a showstopper? Marking nsenterprise-. Tiantian investigate.
Keywords: nsenterprise+ → nsenterprise-
*** Bug 100177 has been marked as a duplicate of this bug. ***
I've been playing with this some and it certainly seems to point to mailnews in my case (as of OS X Mozilla 0.9.4). I can render local on-disk HTML docs, view web pages from the net, and type URLs into the location bar, all without spiking the CPU load to 100% (the 'idle' CPU load on Mozilla appears to hover around 7%) but as soon as I connect to my IMAP server the load goes to 100% and stays there until I click the "offline" button, even if i'm not actively downloading messages, and even if all browser windows are closed. Going back to "online" pushes the CPU back up to 100% even without any other action (and mailnews has been set to *not* re-check for mail every 'n' minutes). I hope this helps someone find the offending code and fix it... I guess the reason I thought before that mozilla was always taking 100% CPU is that I always have been trying to use it as my IMAP client as well, but now it seems that as long as I don't do that I'm OK. Since my information seems to contradict earlier comments about URL entry, etc. maybe this particular bug is actually fixed and my issue is with mailnews alone?
I know exactly what the problem is; don't waste any time trying to narrow it down. We're waiting for the main guys to give us some APIs to allow us to account for open-but-idle mail/news net connections.
Status: NEW → ASSIGNED
s/main/mail
Simon, this is what I had in mind - I added a method to nsIMsgIncomingServer that tells you how many idle connections there are for that server. What you would do is get the mailnews account manager, iterate over the servers in the account, and call this method on each of them. I haven't tested this code, and I haven't done the method for the news server yet; I wanted to make sure this would work for you first.
Patch looks good. 2 comments: + PR_CEnterMonitor(this); ... + PR_CExitMonitor(this); You *really* need a stack-based class that does this safely, otherwise your code is prone to early return problems (tho not in this case). And, this fixes IMAP. What about POP and news -- do they not keep connections open?
> What you > would do is get the mailnews account manager, iterate over the servers in the > account, and call this method on each of them. Could we put the code that does this in some central place in mailnews? Do you have a mailnews service, or something? It seems wrong that mac event code would go grovelling for mailnews account stuff. I'd also have to be careful not to load the mailnews DLLs as a side-effect of making these calls.
yeah, i thought i'd seen reports that news was another cause of this problems. all would be ok until they'd check the news server. ditto on the stack based class.
I already looked at using the stack-based class and decided against it - nsAutoMonitor, I think it was - it does a bunch of extra stuff, and almost all the other routines in this class use what I used. Since I put this in nsIMsgIncomingServer, you won't be pulling in any extra dlls that aren't already loaded, because you can't have any of the servers loaded without having their corresponding dlls loaded. However, if mail/news is not loaded, you shouldn't be calling this code. That would be up to you to figure out, however, I would think, since you can't ask the mailnews code without loading it. I already said that I hadn't done this for news because I wanted to make sure the approach worked for you but I'll say it again: I haven't forgotten news. We don't have a mailnews service - I could put this in the account manager, but I was thinking you might want to have a little control over how this works. If I hide everything, then someone will be more likely to call it blindly and not know how much work is going on underneath. But I can add it to the account manager if that's what you'd prefer, or perhaps nsIMessenger. I would think you should not call this routine every time through your event loop but that's up to you. I'll ask Seth if there's some other global mailnews service that would be better as well, but like I said before, I think you'll be responsible for figuring out if mailnews is already loaded or not, because we can't tell if we're loaded without loading ourself, right?
Ok, I added an attribute on the nsIMsgMailSession for the number of idle connections, and wrote the news server code to count the number of idle connections. It's up to you how often you call this, but I would think you'd want to avoid calling it *every* time through your event loop since it does a non-trival amount of work. Again, I haven't tested any of this code, so let me know if it doesn't work for you. And to answer an earlier question, pop3 and smtp don't cache connections.
Keywords: nsenterprise- → nsbranch
Whiteboard: OSX+ → [OSX+]
That looks great, thanks David. My only comment is that you have copy/pasted a comment in a couple of places where it does not apply: +// default implementation for servers is no idle connections +NS_IMETHODIMP +nsImapIncomingServer::GetNumIdleConnections(PRInt32 *aNumIdleConnections) and +// default implementation for servers is no idle connections +NS_IMETHODIMP +nsNntpIncomingServer::GetNumIdleConnections(PRInt32 *aNumIdleConnections) r=sfraser
d'oh, how embarrassing, I'll get rid of that comment in both places. Cc'ing Seth for sr (though I'd like to know if it works before getting an sr).
nsbranch+, need a patch for PDT+.
Keywords: nsbranch → nsbranch+
stephen - jrgm is out. can you help to verify once there is a fix for the branch?
It seems that it's going to be hard to call the nsIMsgSession API without the side-effect of loading mailnews DLLs. I filed bug 100692 for an API on the component manager to tell me if a service has been instantiated to address this. An alternative solution would be that there is some kind of state that gets set on necko connections when they are 'idle', which I can then query. This makes more sense, since then my code is only dealing with necko APIs, and does not have to have knowledge of the fact that mailnews does special things with its connections. I'm not sure how much work this would be.
It's impossible to call the nsIMsgMailSession api without loading the base mailnews dll, since that's where it lives, and it's the biggest mail dll (by far, I would bet). I was thinking the component mgr should be able to tell you if a service had been instantiated - it knows that, obviously. I think it's much harder for necko to tell if a socket is idle (except by adding some sort of timestamp on the last time data was read or written, I guess).
Another alternative is: maildll on startup notifies observers or notifies a category of its existence and those could trigger other things based on their existence. HTTP does this to cause cookies and others to get loaded. Would that work ?
nsISocketTransportService can tell you how many socket transport objects are allocated along with how many of those are connected and actively polling.
I already call nsISocketTransportService::GetInUseTransportCount() to get "active" connections, but it counts IMAP cached connections as "active", which is the problem here.
so that must mean that IMAP maintains a pending AsyncRead (or AsyncWrite) request for cached (idle) connections... it would be better if IMAP canceled the AsyncRead (or AsyncWrite) request (with a status of NS_OK so the socket wouldn't be closed) instead of holding the socket requests in the pending state and hence on the select list.
I talked to mscott about this. We think it would be too risky for nsbranch for us to cancel our async read because we'd need to make sure we issued another async read when we pulled a connection out of our cache, and that code is tricky, and things would break badly if we got it wrong. Another option is to add a method to nsITransport that we can call to say that we're idle on that socket, and the nsISocketTransportService wouldn't count that socket in GetInUseTransportCount(). This would seem pretty low risk, though I suspect Darin's going to think it's duplicating state that's already kept. Also, in the future, we'd like to support the IMAP Idle command, and that relies on the ability to have a connection idle and listening for data from the server.
it sounds to me like you could keep a list of IMAP connections someplace, and simply subtract the number of IDLE connections from the value returned from nsISocketTransportService::GetInUseTransportCount(). why wouldn't something like this work?
Darin, that's what the patches I've attached do :-) Unless I'm not understanding you.
great! i hadn't looked at the patch... is there any problem with it? is there any reason to believe that it is a sub-optimal solution?
read up, darin.
Pls place ETA in Status Whiteboard, when darin and david have finished talking. Are there any hacks we could use?
Whiteboard: [OSX+] → [OSX+][@risk][ETA?]
I'm not actively working on this - Darin didn't like mscott's idea and mscott didn't like Darin's idea of us cancelling our request (too risky for the branch), so where we are now is I think trying to go with the patch I have, if we can get bug 100692 fixed.
Bug bug 100692 causes api changes That is too risky to do now - impact to plugins, embedding. I think we should meet to talk about this.
Depends on: 100692
After discussion - new xpcom function checked in.
So, after some thought, I have come up with a much simpler patch. Previously, the code that detected the 'busy' state counted in-use network transports, in-use file transports, and whether there were pending events on the main thread's PLEvent queue. There was also some code that avoided transitions between busy and idle states more than once per second. It turns out the simply looking for pending events on the main thread's event queue, with the 1-second hysteresis, is sufficient to provide a good indication of business. This avoids any need to call mail APIs, or detect if services are already loaded. The last patch does this.
I should add that I ran the page-load tests, and the iBench tests, with this patch, and throughout the patch, the state remained 'busy' (#define BUSINESS_INDICATOR to see the transitions between busy and idle). This means that the patch will not impact page-loading performance.
Comment on attachment 50753 [details] [diff] [review] nsMacMessagePump fix r=sdagley (nice and simple)
Attachment #50753 - Flags: review+
r=saari as long as we don't want to count connections on OS9.x either
Comment on attachment 50753 [details] [diff] [review] nsMacMessagePump fix sr=kin@netscape.com
Attachment #50753 - Flags: superreview+
Fix checked into the TRUNK
I can verify the fix works, as designed, on the trunk 0925 build. Much, much better experience! I still suspect that the event loop is too tight when it's in the "busy" state, as it still pegs my 500MHz G4, but it seems to transition itself fine, and it seems to perform just fine for web pages, news, and chat (which, I believe, also used to peg the cpu). My thought is that while eventually moving to the Carbon Event model (or a unix model) from the polling model is the long term solution, this works just fine. Thanks, Simon!
Whiteboard: [OSX+][@risk][ETA?] → [OSX+] [@risk] [ETA 09.26] [PDT]
check it in today - PDT+
Whiteboard: [OSX+] [@risk] [ETA 09.26] [PDT] → [OSX+] [@risk] [ETA 09.26] [PDT+]
Checked into the BRANCH
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Anybody running OS X 10.0.4? jrgm, se? This bug's scope, as filed by Pinkerton, is about doing nothing on a given page, and having the CPU spike. I can verify that on branch build 2001-09-27, using Mac OS X 10.1 and CPU Monitor we spike when loading a new window, but then return to around 1.8-5.3% (sorry, wasn't about to strain my eyesight to count the segments in the standard window of CPU Monitor.) Here's what TOP (usr/bin/login) had to say about the process at the time: PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 318 Netscape 6 4.5% 1:50.61 8 115 411 31.2M- 34.6M 54.3M- 120M Actually, it fluctuated from 1.8-5.3% at any given time, with just this bug report in a single nav window. I'll let someone else with 10.0.4 verify this proper.
10.0.4 running top i got this (one window open) (idle) PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 500 Mozilla 4.2% 1:45.06 7 101 299 41.2M 32.7M 50.2M 128M (loading page) 500 Mozilla 44.7% 2:02.72 7 100 300 41.4M+ 32.7M 50.4M+ 128M running top -dua with this bug page open the largest single spike (while idle) i have seen was to 6.7% of my cpu. On average i see 0.9 to 3.8% on average watching with my eyes...
Verified FIXED, since this has been looked at on both the TRUNK and the BRANCH.
Status: RESOLVED → VERIFIED
*** Bug 134420 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: