Open Bug 705561 Opened 13 years ago Updated 2 years ago

Performance regression on the testcase in bug 424715

Categories

(Core :: Web Painting, defect)

defect

Tracking

()

REOPENED

People

(Reporter: zurtex, Unassigned)

References

Details

(Keywords: perf, regression)

Attachments

(1 file)

Attached file Testcase 1
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.
Keywords: perf, regression
Blocks: 424715, 585258
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....
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.
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?
Nightly 29.0a1 (2013-12-16) - 20.1s
Chrome 31 - 16.4s
IE 11 - 9.5s but doesn't work correctly.
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)
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 → ---
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.
Component: Layout: View Rendering → Layout: Web Painting
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: