Closed Bug 770011 Opened 13 years ago Closed 12 years ago

After landing Bug 539356, Huge performance regression http://sinz.org/Maze/table.html

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox16 - ---
firefox17 - ---
firefox18 - ---

People

(Reporter: alice0775, Assigned: mattwoodrow)

References

(
URL
)

Details

(Keywords: perf, regression)

Build Identifier: http://hg.mozilla.org/mozilla-central/rev/d9d61d199b11 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120701030537 I noticed the problem when I tested Bug 626927. After landing Bug 539356, huge perf regression http://sinz.org/Maze/table.html http://hg.mozilla.org/mozilla-central/rev/f08d285b63b0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120630030532 Maze Complete (Table) Maze size: 89 x 61 (5429 tiles) 224 ms in JavaScript 0.041 ms/tile 21735 ms not in JavaScript 4.003 ms/tile 21959 ms total time 4.044 ms/tile 247.23 tiles per second 11 tiles/step http://hg.mozilla.org/mozilla-central/rev/d9d61d199b11 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120701030537 Maze Complete (Table) Maze size: 89 x 61 (5429 tiles) 238 ms in JavaScript 0.043 ms/tile 103170 ms not in JavaScript 19.003 ms/tile 103408 ms total time 19.047 ms/tile 52.5 tiles per second 11 tiles/step Steps to Reproduce: 1. Prepare a new profile 2. Open http://sinz.org/Maze/table.html Actual Results: 500% slow Expected Results: Not so. Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/0d9f7fb55226 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120629192951 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/cd6d52bdf2d8 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120629200651 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0d9f7fb55226&tochange=cd6d52bdf2d8 Suspected: Bug 539356
With a small window and fast CPU, it looks like the solving beats some timer after which the processing gets MUCH slower. m-c head build vs Chrome on Linux x64 Xeon At ~110x70 - Mozilla is 6-12 times slower, but the amount varies dramatically from run to run. And it's much slower on an in-page re-run vs re-load. Visually, on initial load or reload it's fast for a few seconds then slows down dramatically. At 68x50, speed is on a par with Chrome: 132 JS 1374ms other for Mozilla, 48ms JS 1471ms Chrome (or 1506ms for mozilla, 1519 for Chrome). This appears to be small enough to not hit the slowdown. Hitting "Restart" in Chrome gives similar results +- a few percent, in Mozilla it's 6x slower (again pointing to some sort of timer).
Matt, any idea what's up here?
tracking-firefox16: --- → ?
Assignee: nobody → matt.woodrow
tracking-firefox16: ? → +
DLBI was actually backed out, re-noming while we wait to hear whether this is targeted for 16/17.
tracking-firefox16: + → ?
It appears to be targeting for 17 at this point. Please re-nominate if that isn't the case (or you're still seeing this bug on Aurora 16).
tracking-firefox16: ? → -
tracking-firefox17: --- → +
Can anyone confirm that this is still an issue? The regression range was entirely backed out, so this shouldn't be a problem.
Right, so after the backouts, it's now slower at smaller sizes than with DLBI. On my fast Linux desktop with a self-built m-c build, we're around 3.5ms/tile at 50x35, and 1.1ms/tile at 48x35 (a tiny size difference). Chrome is uniformly around 0.45 ms/tile. At 35x24, we're close to Chrome, but at 67x80 we're around 9ms/tile. Visually you can see the results are a variable rate - at the "small/fast" sizes, especially near the edge of the "fast" size, it alternates between filling in slowly, and poofing-in large chunks faster than the display can refresh (which is similar to chrome).
Please note that if you want to compare runs you should use the benchmark link as it seeds the random number generator to a constant (since things can be different due to the maze internal shape) Use http://sinz.org/Maze/table.html?seed=1 for the link in order to get consistent run-to-run behavior of the maze. (Albeit a 5x difference in performance is well beyond any impact the shape of the maze could have)
So, early (since DLBI just re-landed and I was using an inbound build), but perf seems to be worse than before the landing (only fast at much smaller sizes, instead of ~48x35 before landing, and up to 68x50 in the earlier DLBI landing). Odd. Rebuilding with debug off (it was debug-but-optimized, which isn't really a valid timing test.)
No real difference. At small sizes, it's generally very fast; there's a border where it semi-randomly goes fast or slow (within a run!) using the same seed=1. on my machine, 38x25 is on the border (<~1ms/tile usually). 40x27 was always slow (3.5-4+ms/tile, but sometimes ~2ms/tile, and you can see it jump to much faster in the middle of rendering). 36x23 is almost always fast (0.7-0.9ms/tile, sometimes up to 1.1ms). A differential profile of a fast run and a slow run might be useful to point fingers, but there definitely seems to be some sort of coalescing effect that causes a whole bunch of paints to happen at once (or maybe other no-change paints not to happen) and makes it much, much faster.
Alex: This shouldn't be tracking 16, DLBI got backed out there.
Why is this tracking 17? DLBI (and the paint timing change) isn't there either.
removing tracking 17, putting tracking 18 on so this doesn't fall of our radar when DLBI is landed.
tracking-firefox17: + → -
tracking-firefox18: --- → +
(In reply to Alice0775 White from comment #0) > Build Identifier: > http://hg.mozilla.org/mozilla-central/rev/d9d61d199b11 > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 > ID:20120701030537 > > I noticed the problem when I tested Bug 626927. > After landing Bug 539356, huge perf regression > http://sinz.org/Maze/table.html > > http://hg.mozilla.org/mozilla-central/rev/f08d285b63b0 > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 > ID:20120630030532 > Maze Complete (Table) > Maze size: 89 x 61 (5429 tiles) > 224 ms in JavaScript 0.041 ms/tile > 21735 ms not in JavaScript 4.003 ms/tile > 21959 ms total time 4.044 ms/tile > 247.23 tiles per second 11 tiles/step > > http://hg.mozilla.org/mozilla-central/rev/d9d61d199b11 > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 > ID:20120701030537 > Maze Complete (Table) > Maze size: 89 x 61 (5429 tiles) > 238 ms in JavaScript 0.043 ms/tile > 103170 ms not in JavaScript 19.003 ms/tile > 103408 ms total time 19.047 ms/tile > 52.5 tiles per second 11 tiles/step > > Steps to Reproduce: > 1. Prepare a new profile > 2. Open http://sinz.org/Maze/table.html > > Actual Results: > 500% slow > > Expected Results: > Not so. > > Regression window(m-i) > Good: > http://hg.mozilla.org/integration/mozilla-inbound/rev/0d9f7fb55226 > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 > ID:20120629192951 > Bad: > http://hg.mozilla.org/integration/mozilla-inbound/rev/cd6d52bdf2d8 > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 > ID:20120629200651 > Pushlog: > http://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=0d9f7fb55226&tochange=cd6d52bdf2d8 > > Suspected: Bug 539356 Is this still the case with FF18 at this time ?
Matt let us know that we think we've made as many improvements to DLBI as possible around this, and we're unlikely to take further change here. If this visibly affects any major web properties, please re-nominate.
tracking-firefox18: + → -
Is this still reproducible? In my test Firefox 23 is notable faster than Firefox 17 ESR. Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20100101 Firefox/23.0
Yes Firefox 23 is faster than 17
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Hmm, on my windows 7 machine, this is still _much_ slower than chromium.
On my PC. But, it is little old. Maze Complete (Table) [Firefox 23] Maze size: 108 x 80 (8640 tiles) 349 ms in JavaScript 0.04 ms/tile 66041 ms not in JavaScript 7.643 ms/tile 66390 ms total time 7.684 ms/tile 130.14 tiles per second 11 tiles/step Maze Complete (Table) [Chrome 28] Maze size: 108 x 80 (8640 tiles) 90 ms in JavaScript 0.01 ms/tile 6515 ms not in JavaScript 0.754 ms/tile 6605 ms total time 0.764 ms/tile 1308.09 tiles per second 11 tiles/step I think we should open a new bug.
Please file a new bug about comparison between Chrome and Firefox
You need to log in before you can comment on or make changes to this bug.