103453 - browser startup performance, look at pref calls.

Status: RESOLVED WONTFIX

(SeaMonkey :: General, defect, P2)

Description

[(not reading, please use [e-mail] instead)]

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.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: pref log

Comment 2

[(not reading, please use [e-mail] instead)]

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

[Blake Ross]

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

[Fabian Guisset]

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

[Peter Trudelle]

adding perf keyword, ->pchen/p2/096

Comment 6

[Mitchell Stoltz (not reading bugmail)]

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. 

Comment 7

[(not reading, please use [e-mail] instead)]

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

[Mitchell Stoltz (not reading bugmail)]

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?

Comment 9

[(not reading, please use [e-mail] instead)]

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.

Comment 10

[Paul Chen]

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.