All users were logged out of Bugzilla on October 13th, 2018
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.
Adding keyword perf.
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.
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
QA Contact: jimmylee → jrgm
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
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.
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.
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...
reassigning to pavlov
Assignee: trudelle → pavlov
"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
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
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
qa -> jimmylee, since he has the numbers to compare.
QA Contact: jrgm → jimmylee
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.