Closed Bug 110340 Opened 23 years ago Closed 23 years ago

Launch result numbers up across all platforms.


(SeaMonkey :: UI Design, defect)

Not set


(Not tracked)



(Reporter: jmkobayashi, Assigned: cathleennscp)



(Keywords: perf)


(2 files)

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.
Keywords: perf
QA Contact: sairuh → jrgm
Blocks: 7251
The suspects ->
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: 
20.72/8.37 <--- launch figures from 11/06-11/14 were in the 18s and 19s. 
18.82/8.25 <--- these numbers look good
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?

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 
I've heard rumors that this increase was commercial-tree only, or perhaps

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

             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.

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
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.
Closed: 23 years ago
Resolution: --- → WONTFIX
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.