Closed
Bug 103453
Opened 23 years ago
Closed 23 years ago
browser startup performance, look at pref calls.
Categories
(SeaMonkey :: General, defect, P2)
Tracking
(Not tracked)
RESOLVED
WONTFIX
mozilla0.9.6
People
(Reporter: sspitzer, Assigned: paulkchen)
References
(Depends on 1 open bug)
Details
(Keywords: perf)
Attachments
(1 file)
13.87 KB,
text/plain
|
Details |
something we're looking at for mailnews is to see if we are abusing prefs
(especially the char prefs) in any way.
in my debug win2k build, I started browser (mozilla -P sspitzer about:blank)
and open a second browser (the pref is set to open about:blank)
I'll attach the pref calls that were made in doing that.
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
if you are curious, the mail version of this bug is #103444
here are the the most common calls in opening up two browser windows to
abou:blank:
35 XXX copy pref capability.policy.default.Window.scriptglobals
34 XXX copy pref capability.policy.default.Window.scriptglobals.set
32 XXX bool pref javascript.options.werror
32 XXX bool pref javascript.options.strict
31 XXX copy pref intl.accept_languages
11 XXX copy pref font.default
Comment 3•23 years ago
|
||
Thanks for doing this. javascript.options.werror and javascript.options.strict
*32*, wtf?! Cc'ing jst.
Also cc'ing mstoltz since his capability prefs are the reigning champs right now ;)
Comment 4•23 years ago
|
||
We check for javascript.options.strict and .werror in the constructor of
nsJSContext:
http://lxr.mozilla.org/mozilla/source/dom/src/base/nsJSEnvironment.cpp#384.
Apparently this constructor is called only by NS_CreateScriptContext() which is
called by nsDOMSOFactory::NewScriptContext().
I could find only three places calling this last method:
/docshell/base/nsDocShell.cpp, line 5967
/content/xbl/src/nsBindingManager.cpp, line 217
/content/xul/document/src/nsXULPrototypeDocument.cpp, line 615
Note that the nsJSContext is cached after having been created. How often are all
those functions called?
Comment 5•23 years ago
|
||
adding perf keyword, ->pchen/p2/096
Comment 6•23 years ago
|
||
Are pref accesses really that expensive? They're basically just a hashtable
lookup and (for char prefs) a string alloc & copy. I looked at some Quantify
data on opening a window to about:blank, and the amount of time spent in
nsScriptSecurityManager, including the pref accesses, is pretty much off the
radar - maybe 0.01%.
That being said, I am experimenting with a new system for the security manager
which doesn't call prefs every time. I'll see if it actually improves performance.
Reporter | ||
Comment 7•23 years ago
|
||
keep in mind, while calling CopyCharPref() 31 times isn't going to slow us
down, it might be exposing a problem that is slowing us down.
Comment 8•23 years ago
|
||
I don't understand...if Quantify says that nsScriptSecurityManager
initialization plus all of its decendants are hardly taking any time at all,
then how can you say it's slowing us down?
Reporter | ||
Comment 9•23 years ago
|
||
I'm not claiming that your code is slowing us down. I'm saying look at the pref
calls for performance hot spots.
what ever is calling
CopyCharPref("capability.policy.default.Window.scriptglobals") 35 times might be
doing something else 35 times.
I put some printfs in prefapi.c, and these are my findings for about:blank.
if there is nothing here, feel free to mark it invalid.
Assignee | ||
Comment 10•23 years ago
|
||
Couldn't find where nsScriptSecurityManager accesses
capability.policy.default.Window.scriptglobals and
capability.policy.default.Window.scriptglobals.net, but as Fabian pointed out,
the javascript.options.* prefs are accessed whenever we create a new js context.
And yes, we create a lot of them. Unless someone else wants to take a crack at
this, I'm marking wontfix.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•