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: 23 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: 23 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: