Bommels05/Mozilla
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix comments in patch that fixes performance regression from bug 395397 -- comment-only patch. b=396796 r=josh a=josh

Browse Source 
git-svn-id: svn://10.0.0.236/trunk@236733 18797224-902f-48f8-a5cc-f745e15eee43
This commit is contained in:
smichaud%pobox.com
2007-09-26 23:05:34 +00:00
parent 7825620793
commit 223273fdaa
2 changed files with 19 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
mozilla/widget/src/cocoa/nsAppShell.h
View File

@@ -90,6 +90,11 @@ protected:
// mHadMoreEventsCount and kHadMoreEventsCountMax are used in
// ProcessNextNativeEvent().
PRUint32 mHadMoreEventsCount;
// Setting kHadMoreEventsCountMax to '10' contributed to a fairly large
// (about 10%) increase in the number of calls to malloc (though without
// effecting the total amount of memory used). Cutting it to '3'
// reduced the number of calls by 6%-7% (reducing the original regression
// to 3%-4%). See bmo bug 395397.
static const PRUint32 kHadMoreEventsCountMax = 3;
};

30
mozilla/widget/src/cocoa/nsAppShell.mm
View File

@@ -414,22 +414,20 @@ nsAppShell::ProcessNextNativeEvent(PRBool aMayWait)
// combining [NSRunLoop runMode:beforeDate] with [NSApp
// nextEventMatchingMask:...].
// We need to special-case timer events (events of type NSPeriodic),
// otherwise we will starve them. (Which can have strange results --
// among other things it causes a ~10% increase in the number of calls
// to malloc and a ~2% Tdhtml regression. See bmo bug 396796.) Apple's
// documentation is very scanty, and it's now more scanty than it used to
// be. But it appears that [NSRunLoop acceptInputForMode:beforeDate:]
// doesn't process timer events at all, that it is called from
// [NSRunLoop runMode:beforeDate:], and that [NSRunLoop runMode:beforeDate:],
// though it does process timer events, doesn't return after doing so.
// To get around this, when aWait is PR_FALSE we check for timer events
// and process them using [NSApp sendEvent:]. When aWait is PR_TRUE
// [NSRunLoop runMode:beforeDate:] will only return on a "real" event.
// But there's code in ProcessGeckoEvents() that should (when need be)
// wake us up by sending a "fake" "real" event. (See Apple's current doc
// on [NSRunLoop runMode:beforeDate:] and a quote from what appears to be
// an older version of this doc at
// We special-case timer events (events of type NSPeriodic) to avoid
// starving them. Apple's documentation is very scanty, and it's now
// more scanty than it used to be. But it appears that [NSRunLoop
// acceptInputForMode:beforeDate:] doesn't process timer events at all,
// that it is called from [NSRunLoop runMode:beforeDate:], and that
// [NSRunLoop runMode:beforeDate:], though it does process timer events,
// doesn't return after doing so. To get around this, when aWait is
// PR_FALSE we check for timer events and process them using [NSApp
// sendEvent:]. When aWait is PR_TRUE [NSRunLoop runMode:beforeDate:]
// will only return on a "real" event. But there's code in
// ProcessGeckoEvents() that should (when need be) wake us up by sending
// a "fake" "real" event. (See Apple's current doc on [NSRunLoop
// runMode:beforeDate:] and a quote from what appears to be an older
// version of this doc at
// http://lists.apple.com/archives/cocoa-dev/2001/May/msg00559.html.)
// If the current mode is something else than NSDefaultRunLoopMode, look