110340 - Launch result numbers up across all platforms.

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, defect)

Description

[Jennifer Kobayashi]

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.

Comment 1

[Jennifer Kobayashi]

Attachment: launch results spreadsheet

Attaching launch results

Comment 2

[Asa Dotzler [:asa]]

not a good idea to assign bugs like this to browser-general. -> apps.

Comment 3

[Mike Jaques]

The suspects -> http://bonsai.mozilla.org/toplevel.cgi?
treeid=default&batchid=670

Comment 4

[Jennifer Kobayashi]

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!

Comment 5

[Mike Jaques]

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.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 7

[Peter Trudelle]

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?

Comment 8

[jag (Peter Annema)]

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.

Comment 9

[jag (Peter Annema)]

Attachment: patch used for testing

Comment 10

[jag (Peter Annema)]

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

Comment 11

[jag (Peter Annema)]

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.

Comment 12

[jag (Peter Annema)]

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.

Comment 13

[jag (Peter Annema)]

-> cathleen

Cathleen, could you spend some time with this?

Comment 14

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