Closed Bug 103453 Opened 23 years ago Closed 23 years ago

browser startup performance, look at pref calls.


(SeaMonkey :: General, defect, P2)

Windows 2000


(Not tracked)



(Reporter: sspitzer, Assigned: paulkchen)


(Depends on 1 open bug)


(Keywords: perf)


(1 file)

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.
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 

     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

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 ;)
We check for javascript.options.strict and .werror in the constructor of
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?
adding perf keyword, ->pchen/p2/096
Assignee: trudelle → pchen
Keywords: perf
Priority: -- → P2
Target Milestone: --- → mozilla0.9.6
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. 
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.
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?
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.
Depends on: 105757
Blocks: 7251
Couldn't find where nsScriptSecurityManager accesses
capability.policy.default.Window.scriptglobals and, 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.

Closed: 23 years ago
Resolution: --- → WONTFIX
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.