All users were logged out of Bugzilla on October 13th, 2018

Major degradation with performance of installing files

VERIFIED FIXED in M18

Status

()

P3
normal
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: jimmykenlee, Assigned: dveditz)

Tracking

({perf})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+] ETA: 7/18)

(Reporter)

Description

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

Comment 1

19 years ago
Adding keyword perf.
Keywords: perf
(Reporter)

Comment 2

19 years ago
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.
Keywords: nsbeta3
(Assignee)

Comment 3

19 years ago
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.
Assignee: dveditz → trudelle
Component: Installer: XPInstall Engine → XP Toolkit/Widgets
Keywords: nsbeta2
QA Contact: jimmylee → jrgm

Comment 4

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

Comment 5

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

Comment 6

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

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

19 years ago
[nsbeta2+]
Whiteboard: [nsbeta2+]

Comment 9

19 years ago
reassigning to pavlov
Assignee: trudelle → pavlov
Target Milestone: --- → M18
"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.
Assignee: pavlov → dveditz
(Assignee)

Comment 11

19 years ago
For a band-aide fix on our end, won't solve the basic layout/dialog slowness 
jimmy's numbers show.
Whiteboard: [nsbeta2+] → [nsbeta2+] ETA: 7/18
(Assignee)

Comment 12

19 years ago
Fixed, as suspected the dialog repainting was taking all the time. Now we 
update the dialog 4 times a second at most..
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 13

19 years ago
qa -> jimmylee, since he has the numbers to compare.
QA Contact: jrgm → jimmylee
(Reporter)

Comment 14

19 years ago
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!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.