data from instrumenting startup code showing that we're opening and accessing files from classic.jar, even when modern skin is the default. Need to figure out why and where this is happening, and fix that. see data posted on http://mozilla.org/performance/startup-data/timings.html
cc'ing dveditz, ssu.
What if you bypass the profile manager?
how do I bypass profile manager? we only have one profile on the machine. I am going to delete the old profile create a clean one today, and hook up with rogc and do another run of test to see if classic.jar is still being opened or not.
try -P profilename, however if you only have one profile i would hope it doesn't get loaded at all...
startup perf ==> pchen
Assignee: vishy → pchen
new timeline data, with a clean profile, still showing classic.jar gets read during startup. first launch: http://mozilla.org/performance/startup-data/nscp-timings-reboot.html relaunch: http://mozilla.org/performance/startup-data/nscp-timings-warm.html
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.1
yeah, we shouldn't be doing this, but it's not going to significantly reduce startup time. pushing out to 0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Moving to mozilla1.0 timeframe, we're going to focus more on ironing out the -turbo issues in m0.9.2.
Target Milestone: mozilla0.9.2 → mozilla1.0
perf -> moving up a bit.
Target Milestone: mozilla1.0 → mozilla0.9.5
We open classic.jar as a result of calling nsChromeRegistry::InstallSkin(). I think that's valid, and that's the only reason we open classic.jar as far as I can tell. The timeline is a little misleading since you don't have more context to see why classic.jar is getting opened. Marking wontfix, cc-ing hyatt to see if he wants to weigh in.
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.