On 11/15 trunk builds: In today's startup results, there was an 1-3 second increase across all platforms. haven't been able to run startup on mac or linux for a few days, due to loss of network connectivity in the the labs, however windows results were holding steady until today's jump.
Attaching launch results
not a good idea to assign bugs like this to browser-general. -> apps.
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Summary: Launch result numbers up across all platforms. → Launch result numbers up across all platforms.
The suspects -> http://bonsai.mozilla.org/toplevel.cgi? treeid=default&batchid=670
Linux numbers stabilized, don't look too bad today. Windows launch is still up about a second (rather than two), relaunch looks better. Mac is still up quite a bit from what we were seeing.. Numbers from 11/20 are as follows: win 20.72/8.37 <--- launch figures from 11/06-11/14 were in the 18s and 19s. linux 18.82/8.25 <--- these numbers look good mac 24.37/15.45 <--- Ouch. These numbers aren't so hot. The launch figures seem to bounce around, but I've been seeing them as low as 21s. There were down to 21.82 yesterday, but spiked again today. Relaunch has been consistently bad since 11/15. We've gained a few seconds there. Thanks!
Sadly no ones jumping all over this. Would it not be prudent to get al those that checked in on the 14th to review there code for anything that may have had the drastic (1-2 seconds is fairly drastic in my humble opinion here) effect on startup time? http://bonsai.mozilla.org/showcheckins.cgi?&batchid=670 Times are slowly coming back down, but I'm guessing its due to other optimizations, and not to fixing the bug that pegged startup time up across all platforms.
I've heard rumors that this increase was commercial-tree only, or perhaps builds-with-crypto-only. Also, please don't spam the whole hook just because you think this is getting ignored. That's not the way to solve problems like this -- it just overloads people with email they don't need. (And you didn't even cc: yourself.) Once we figure out how to reproduce the regression it should be easy (although perhaps time-consuming) to figure out which checkin caused it. However, that's much less time-consuming than staring at code trying to find the problem.
I'm not sure who we could doom to searching for this, but a 1-3 second degradation in startup is extremely alarming, certainly worth spamming the hook about. Too bad we didn't close the tree immediately. ->jaggernaut for starts, since he either checked in or reviewed a lot of string changes during this time. Jag, can you demonstrate that startup was at least as fast with those changes as before?
Assignee: pchen → jaggernaut
The change from NS_ConvertASCIItoUCS2("...") to NS_LITERAL_STRING("...") means that on Mac and Windows we're trading code size for performance, in that the literal strings as stored in the binary have doubled their size (from char to PRUnichar) but now don't have to be converted at runtime. On Linux (currently) NS_LITERAL_STRING is defined in terms of NS_ConvertASCIItoUCS2, so no change there makes sense. I'll perform some tests.
Status: NEW → ASSIGNED
The above patch makes NS_LITERAL_STRING always use NS_ConvertASCIItoUCS2("...") instead of nsDependentString(L"...") as an easy way to measure the cost/benefit of using L"" instead of runtime conversion from ASCII to UCS-2. The tests: startup : time ./mozilla -P test file:///c:/temp/close.html (run 10 times from a shell script) new window : winopen.xul page load : cowtools, 5 cycles at 1,000ms The results: NS_ConvertASCIItoUCS2("...") nsDependentString(L"...") startup avg: 2.037s, med: 2.036s avg: 2.020s, med: 2.013s new window avg: 0.300s, med: 0.300s avg: 0.300s, med: 0.300s page load avg: 0.497s, med: 0.497s avg: 0.491s, med: 0.493s
Since the nsDependentString build wasn't a clobber build I ran these tests again: NS_ConvertASCIItoUCS2("...") nsDependentString(L"...") startup avg: 2.080s, med: 2.076s avg: 2.077s, med: 2.076s new window avg: 0.310s, med: 0.310s avg: 0.310s, med: 0.310s page load avg: 0.494s, med: 0.494s avg: 0.492s, med: 0.491s binary size 18,646kB 18,594kB I didn't change anything about the NS_ConvertASCIItoUCS2 build, so I guess my machine is just moody.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=11%2F14%2F2001+00%3A00%3A00&maxdate=11%2F15%2F2001+06%3A00%3A00&cvsroot=%2Fcvsroot Above is the list of checkins from 11/14/2001 00:00:00 and 11/15/2001 06:00:00. This list does not have bzbarsky's string changes, which were on the 13th, while the numbers went up somewhere after the 10 am builds on the 14th. Within the above list I do not see an obvious candidate for the 2s uptick.
-> cathleen Cathleen, could you spend some time with this?
Assignee: jaggernaut → cathleen
Status: ASSIGNED → NEW
check-in log is way too big to go through... :-( Unfortunately, testerbox wasn't implemented at the time, to help us narrow down to a percise time frame for a smaller set of check-ins, so I think I'm going to mark this as WONTFIX. We have testerbox in place now, and we're watching tinderbox test numbers closely, so hopefully this type of regression won't happen again.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.