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.
adding perf keyword, ->pchen/p2/096
Assignee: trudelle → pchen
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.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.