Open
Bug 705561
Opened 13 years ago
Updated 2 years ago
Performance regression on the testcase in bug 424715
Categories
(Core :: Web Painting, defect)
Core
Web Painting
Tracking
()
REOPENED
People
(Reporter: zurtex, Unassigned)
References
Details
(Keywords: perf, regression)
Attachments
(1 file)
3.42 KB,
text/html
|
Details |
Mild performance regression in DOM based rendering from bug 424715. Steps to reproduce: 1. Open Browser with Fresh Profile 2. Open attached "Testcase 1" 3. Press "Full Render" 4. Not down time taken. Expected Result: Competitive with other browsers Actual Results: With fresh install of Windows 7 (SP1) x64, running relatively high end system produced these results ordered by time taken: Opera Version 11.52 Build 1100: 2.513 seconds Google Chrome 17.0.951.0 canary: 13.313 seconds Firefox Gecko/20100713 Minefield/4.0b2pre: 13.267 seconds Internet Explorer 9: 13.498 Seconds Firefox Gecko/20111127 Firefox/11.0a1: 33.522 seconds Firefox Gecko/20100716 Minefield/4.0b2pre: 227.589 seconds There was a huge regression between builds 20100713 and 20100716, since then time taken has slowly improved. But responsiveness and memory usage also very poor compared to other browsers. Low priority bug, but hopefully someone can use to expose problems with Firefox performance vs. other browsers.
Reporter | ||
Updated•13 years ago
|
Keywords: perf,
regression
Reporter | ||
Updated•13 years ago
|
Comment 1•13 years ago
|
||
Regression from when to when? The big regression you're seeing is basically what bug 585258 was about, yes? And that bug's dependencies cover what time is spent on with this testcase....
Reporter | ||
Comment 2•13 years ago
|
||
I'll get some numbers but it seems that bug 585258 only improved performance to pre bug 424715 levels and did not fix the actual regression of build 20100716. Only open dependency was bug 539356. Therefore I created a new bug which tracked performance. I'm hypothesising independent bugs improved performance of this test case, I will get numbers to back it up.
Comment 3•13 years ago
|
||
There was analysis in one of these many bugs pinning things down to the fact that display list construction ends up O(N^2) in this case, no?
Comment 4•11 years ago
|
||
Nightly 29.0a1 (2013-12-16) - 20.1s Chrome 31 - 16.4s IE 11 - 9.5s but doesn't work correctly.
Comment 5•8 years ago
|
||
Um... have you filed a bug on the 50% regression from 46 to nightly?
Flags: needinfo?(roxana.leitan)
20160502172042 Mozilla/5.0 (Windows NT 6.1; rv:46.0) Gecko/20100101 Firefox/46.0 20160524073714 Mozilla/5.0 (Windows NT 6.1; rv:49.0) Gecko/20100101 Firefox/49.0 I have tested your issue on latest FF release 46.0.1 and latest Nightly build 20160524073714 and could not reproduce it. FF 46.0.1: 15.899 seconds FF latest Nightly: 23.746 seconds Chrome: 12.176 seconds IE: 11.062 seconds Based on above results I will mark this as Resolved-Worksforme. If anyone can still reproduce it, feel free to reopen the issue and provide more information.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
New bug logged for this issue Bug 1276160
Flags: needinfo?(roxana.leitan)
Reporter | ||
Comment 8•8 years ago
|
||
Please don't close as WFM when you mean duplicate, it removes the ability to navigate the dependency tree. Also really bug 1276160 is a duplicate of this bug as this bug was never resolved.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 9•8 years ago
|
||
Although I see bug 1276160 is specific to a small regresion window, it's probably worth noting that between 2011 and 2016 Chrome also seems to have regressed 100%. Though this number is a bit of a misnomer as the test is O(n^2), you could make any linear performance decrease look arbitarily bad.
Assignee | ||
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
Updated•2 years ago
|
Severity: minor → S4
You need to log in
before you can comment on or make changes to this bug.
Description
•