browser startup performance, look at pref calls.

RESOLVED WONTFIX

Status

P2
normal
RESOLVED WONTFIX
17 years ago
14 years ago

People

(Reporter: sspitzer, Assigned: paulkchen)

Tracking

(Depends on: 1 bug, {perf})

Trunk
mozilla0.9.6
x86
Windows 2000
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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

17 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

17 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

17 years ago
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.

Updated

17 years ago
Depends on: 105757

Updated

17 years ago
Blocks: 7251
(Assignee)

Comment 10

17 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
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.