Launch result numbers up across all platforms.

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
17 years ago
5 years ago

People

(Reporter: jmkobayashi, Assigned: cathleennscp)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Created attachment 57974 [details]
launch results spreadsheet

Attaching launch results

Comment 2

17 years ago
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
(Assignee)

Updated

17 years ago
Blocks: 7251

Comment 3

17 years ago
The suspects -> http://bonsai.mozilla.org/toplevel.cgi?
treeid=default&batchid=670
(Reporter)

Comment 4

17 years ago
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

17 years ago
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.

Comment 7

17 years ago
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

Comment 8

17 years ago
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

Comment 9

17 years ago
Created attachment 63349 [details] [diff] [review]
patch used for testing

Comment 10

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
-> cathleen

Cathleen, could you spend some time with this?
Assignee: jaggernaut → cathleen
Status: ASSIGNED → NEW
(Assignee)

Comment 14

17 years ago
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
Last Resolved: 17 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.