42548 - Major degradation with performance of installing files

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Jimmy Lee]

Build: 2000-06-12-21-M17(WIN), 2000-06-12-20-M17(MAC), 2000-06-12-20-M17(LINUX)

1. From http://jimbob/trigger3.html, enter http://jimbob/jars/p_browser2.xpi
2. Click Trigger button
3. Click Install button from the confirmation dialog

RESULT:
Installation takes a long time (ie > 100% for Mac).  Check the install.log which 
contains some JS code to collect the install time.  Using older builds like M16 
does not exhibit similar behavior.  A table tabulating these figures can be 
found at http://jimbob/smartupdate/smartupdate_performance.html

EXPECTED RESULT:
No extreme degradation in performance.

Comment 1

[Jimmy Lee]

Adding keyword perf.

Comment 2

[Jimmy Lee]

Nominating for nsbeta3.

Compared to Beta1, the install engine now takes about 4 times longer on Mac, 3 
times longer on Windows, and 2.75 times longer on Linux.

Comment 3

[Daniel Veditz [:dveditz]]

Nominating for nsbeta2 -- installing browser-only on a Mac now takes 10 
minutes not counting download time. This UI regression has affected other 
parts of the product as well, and happened when nothing went into the 
XPInstall engine itself. I'm going to blame XPToolkits, although it could be 
the ender-lite stuff that went in over the weekend.

Comment 4

[Peter Trudelle]

Don't see how the Toolkit could be causing this - why are you calling and 
engine slowdown a UI regression? Weren't other recent performance regressions 
due to string changes?  cc scc

Comment 5

[Daniel Veditz [:dveditz]]

The part that appeared to slow down was updating status text in our 
progress dialog. It may be string related, but it's behind the dialog APIs 
we're using.

Comment 6

[Daniel Veditz [:dveditz]]

I'm trying to get a Quantify run on it, but have been stuck in meetings all 
day. I have a run from before the slowdown I can compare to and will reassign 
the bug if I find a better home for it.

Comment 7

[Peter Trudelle]

Hasn't that always taken some significant amount of time, especially on Mac? 
Can't we just cut it altogether? I doubt many users really care that we are 
installing *.shlb...

Comment 8

[Phil Peterson]

[nsbeta2+]

Comment 9

[Peter Trudelle]

reassigning to pavlov

Comment 10

[Mike Pinkerton (not reading bugmail)]

"I'm going to blame XPToolkit" doesn't quite cut it. Pushing back to dveditz 
until he can get quantify data that shows where the blame is. At that time, we'll 
be happy to take it if it turns out to be toolkit.

Comment 11

[Daniel Veditz [:dveditz]]

For a band-aide fix on our end, won't solve the basic layout/dialog slowness 
jimmy's numbers show.

Comment 12

[Daniel Veditz [:dveditz]]

Fixed, as suspected the dialog repainting was taking all the time. Now we 
update the dialog 4 times a second at most..

Comment 13

[John Morrison]

qa -> jimmylee, since he has the numbers to compare.

Comment 14

[Jimmy Lee]

Build: 2000-07-19-20-M17(MAC), 2000-07-19-21-M17(WIN), 2000-07-19-20-M17(LINUX)

Performance is much faster now.  It's a dramatic difference.
http://jimbob/smartupdate/smartupdate_performance.html

Marking Verified!