Closed Bug 1409047 Opened 7 years ago Closed 3 years ago

My old Maze test is now an order of magnitude slower than Chrome and Edge

Categories

(Core :: Layout: Tables, defect, P3)

Product:
Core
Component:
Layout: Tables
Version:
57 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Project Flags:
Performance Impact medium
Tracking Flags:
Tracking Status
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox-esr91 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox98 --- wontfix
firefox99 --- wontfix
firefox100 --- wontfix

People

(Reporter: mks, Unassigned, Mentored)

References

(Regression,
URL
)

Details

(Keywords: perf, perf:pageload, regression)

Attachments

(2 files)

jprof_maze.html
(deleted), text/html
Details
Templatization, for future reference
(deleted), patch
Details | Diff | Splinter Review
Many years ago, I wrote a fun web page with my daughter who was into mazes. At the time I did it in Firefox as, well, it is my browser of choice. At the time, it turned out that Firefox was the fastest as rendering said maze (and solving it). It was a few orders of magnitude faster than IE (so much so that I thought it crashed on IE) I don't go back to that page much after having added lots of instrumentation and testing code to it in order to show it as a benchmark of something bad in IE (and other browsers) Since that time, the other browsers have significantly improved but Firefox has degraded. Now, with Beta57, the performance is unusable. It is easily over 10 times slower than Chrome or Edge or IE on the same system. http://sinz.org/Maze/ Got to http://sinz.org/Maze/table.html?seed=1 for a consistent random seed (thus the maze will always be the same if the screen/window size is the same) The difference in performance is startling - something that used to, in order Firefox version (I don't have 56 on my machine at the moment but I mean much older) fly through the generation process now just crawls. It is actually painful to watch after seeing how Chrome or IE handle the same URL. The page is fully static and the HTML/CSS/JS is downloadable in a zip file from the site. It has not changed in many years so it likely is not "the latest style" and it was hacked on to add the telemetry and to make it able to switch out different layout mechanisms. Note that even the hover-underline of the links once the rendering is done is very slow and that is not at all based on any JS in the page. Something very wrong is going on here.
The instrumented difference on my machine for exactly the same display size is: Chrome: 337.82 tiles/second IE: 339.44 tiles/second Firefox: 33.68 tiles/second Time in JavaScript: Chrome: 0.026 ms/tile IE: 0.120 ms/tile Firefox: 0.024 ms/tile Time not in JavaScript: Chrome: 3.005 ms/tile IE: 2.869 ms/tile Firefox: 29.659 ms/tile (These numbers are from the code itself, so they are impacted by observation artifacts. (That is, they add overhead all on their own) The reason I even pulled this out was that my music library page, which does not use a complex table but does have a small table with 6 rows and 2 columns seems to have gotten rather slow with the hover effect on names. As in multiple seconds before it highlights the name. This used to not be a problem on Firefox and is not a problem in Chrome so I pulled out this fine little benchmark to see if this was just my simple music player or not.
URL: http://sinz.org/Maze/table.html?seed=1
Note that the "No Table" variant on Firefox is noticeably faster at 125.62 tiles/second. So there is definitely some interaction with the table layout code but the "No Table" version is still over half as fast as the same in IE/Chrome. (In fact, in Chrome, No Table is slower than Table while in IE, No Table is faster by about double: NoTable variant: Chrome: 288.19 tiles/second IE: 624.37 tiles/second Firefox: 125.62 tiles/second
See bug #626927 as that was the first time I reported a regression many years ago.
Gecko Profiler run: https://perfht.ml/2xKEZDn (Oddly this capture didn't seem to show anything... https://perfht.ml/2xK1wjq) (in Nightly 58) (Table version, "Benchmark" entry) Content #4. >7s event processing delay, and lots more... Most of the cpu used is in PaintRowGroupBackgroundByColIdx() in a number of sub-methods 15% of the total directly in do_QueryFrameHelper::operator nsTableCellFrame *() >20% in nsTableCellFrame::ShouldPaintBordersAndBackgrounds() (mostly in this method, not what it calls) Actually those are both low: that covers ~70% of the CPU use. ~29% is in mozilla::SchedulerGroup::Runnable::Run(), which ends up in the exact same place (from a different top-level invocation). So the CPU is all in PaintRowGroupBackgroundByColIdx() pretty much. More to the question would be why we spend time there, not micro-optimizing the implementation (though there may be fubar's, like why it spends so much time in QueryFrameHelper or ShouldPaint...). The analysis in bug 626927 is likely still relevant, though perhaps things have gotten worse (if so, regression search with mozregression would be good). This is pretty crazy-slow... though perhaps is not a common case-on-the-web, but even in non-perf-collapse cases we may be much less efficient than we need to be. given the focus on perf for 57/58, someone should recheck the analysis and profiles. Ehsan isn't taking NI requests. bz did the analysis on the older bug
status-firefox56: --- → wontfix
status-firefox57: --- → affected
status-firefox58: --- → affected
Component: Untriaged → Graphics
Flags: needinfo?(milan)
Flags: needinfo?(bzbarsky)
Flags: needinfo?(bugs)
Keywords: perf
Product: Firefox → Core
Whiteboard: qf:?
Attached file jprof_maze.html (deleted) —
jprof profile; shows similar results. Top direct hit is also PaintRowGroupBackgroundByColIdx() with 24.5% in that function, and 18% in ShouldPaintBordersAndBackgrounds(). Even GetColIndex() is 12% direct hits.
Sounds like Layout more than graphics, based on your profiling.
Component: Graphics → Layout: Tables
Also: just mousing over a link in the "results" box causes very slow response; a quick profile shows 240ms blocks sitting 100% inside PaintRowGroupBackgroundByCollIdx on each mouse-over-a-link-at-the-bottom. https://perfht.ml/2xLMTfs I put it in Graphics because the older bug on this that bz investigated was put there; this is all in building display lists, which I believe falls in gfx. Milan?
There's multiple regressions here. But trying to track them all down has been a pain. For reference, I get a score of around 350 tiles/sec on the seed=1 testcase on a build from February 2015. On a current trunk nightly, that score is closer to 60-65. The most obvious regression range I've found so far was the drop from ~146 to ~63 tiles/sec: INFO: Last good revision: 33df8c04309cf792b214c5c6c903a391048f5516 INFO: First bad revision: 2a15fd71cf351e12c1286139e53b42b4cc486141 INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=33df8c04309cf792b214c5c6c903a391048f5516&tochange=2a15fd71cf351e12c1286139e53b42b4cc486141 --> Bug 929484 However, it's been much more difficult pinning down what got me from the mid-300s to the mid-100s before that, as that appears to have been much more gradual over time (combined with not having a good picture for what the overall margin of error for the test is, and hence what makes a given build good or bad). Anyway, I don't think bug 929484 is a surprising result and hopefully that at least helps point enough at what could be going wrong here to make progress.
Blocks: 929484
status-firefox-esr52: --- → wontfix
Keywords: regression
So fundamentally, building the display list for the table is super-slow. The profile in comment 4 has 9618 samples in the "Content #4" process; of those the vast majority are under PaintRowGroupBackgroundByColIdx. This is in fact kind of "Graphics" code in terms of who tends to modify it, even though it lives in the layout directory. There's one confusing thing about the Gecko profiler profile above: it claims that nsTableFrame::BuildDisplayList calls nsTableFrame::DisplayGenericTablePart which calls PaintRowGroupBackgroundByColIdx, but that's not a possible callstack as far as I can tell. To land in PaintRowGroupBackgroundByColIdx you have to come into nsTableFrame::DisplayGenericTablePart from nsTableColGroupFrame::BuildDisplayList or nsTableColFrame::BuildDisplayList. Maybe those functions got coalesced with nsTableFrame::BuildDisplayList somehow because they're all binary-identical? Or maybe there's LTO going on and various stuff got inlined somehow? Anyway, as RyanVM points out there was a significant regression from bug 929484, which reorganized this display-list building code. And indeed, if I run http://sinz.org/Maze/table.html?seed=1 in Firefox 54 (before bug 929484), I get "168.81 tiles per second" while in Firefox 55 I get "76.28 tiles per second". On the same hardware, Chrome gets "639.24 tiles per second" at the same window size. Today's nightly gets "80.24 tiles per second". Alright, so in terms of things that might make this better: * We can and should do some micro-optimization here; the table code is doing some stupid things that we can get rid of (e.g. that "do_QueryFrameHelper::operator nsTableCellFrame *" thing is wholly unnecessary). I'll file some bugs on specific "fix the stupid bits" things once my opt build is done and I can do some measurements. * It's possible that bug 1352499 will help. Once bug 1404181 lands we should flip the pref and retest here, just to check that hypothesis. * The basic structure of the table display list construction code after bug 929484 is like this: 1) Walk through all the rowgroups. For each rowgroup, walk the rows. For each row, walk the cells. Whenever we walk something, add the relevant backgrounds to the display list. Actually, we walk the rows/cells twice, effectively: once to paint rowgroup backgrounds and again to paint row backgrounds. 2) Walk through the column groups. For each column group, walk all the rows. For each row, walk all the cells, add the colgroup background to the display list for the ones that are inside the relevant colgroup. There's only one colgroup in this case, so this is just another walk over "all cells" in practice. Now we're at 3 walks over the cells. 3) Walk through the columns. For each column, do exactly the work we did above for column groups. This is the part where the suck sets in. The table in question has, at my window size, 235 columns. That means we have an additional 235 walks over all the cells. Given that the walk is not nearly as cheap as it could be (see above about "stupid bits"), this is bad. I filed bug 1409114 on this third bullet point, because item 3 in particular is silly and we should fix that.
Depends on: 1352499, 1404181, 1409114
Flags: needinfo?(bzbarsky)
Just a thought, once this is back under control, is it worth using this as part of automated tests to prevent performance regressions?
Sure would be nice.... If only adding automated perf tests were not rocket science. :(
Depends on: 1409140
Depends on: 1409152
Depends on: 1409154
Unfortunately retained display lists do not help here yet at least. The maze demo seems to trigger a complete rebuild of the display list, with only minimal reuse of items. [{ "retained": 538.140, "full": 529.225, "modifiedFrames": 101, "merged": 1, "items": { "list": 55141, "old": 55141, "new": 55131, "reused": 12 } }, { "retained": 570.322, "full": 565.384, "modifiedFrames": 53, "merged": 1, "items": { "list": 55141, "old": 55141, "new": 55131, "reused": 12 } }]
Depends on: 1409162
> There's one confusing thing about the Gecko profiler profile above: it > claims that nsTableFrame::BuildDisplayList calls > nsTableFrame::DisplayGenericTablePart which calls > PaintRowGroupBackgroundByColIdx, but that's not a possible callstack as far > as I can tell. jprof shows the same sequence (gcc, linux, opt build)
Some numbers around my first bullet point: Clean local build: 93 tiles/sec With bug 1409140 fixed: 105 tiles/sec Also with bug 1409154 fixed: 145 tiles/sec Also with bug 1409162 fixed: 159 tiles/sec I might be able to squeeze a bit more out of it, but really we need to fix bug 1409114.
For what it's worth, I tried also templatizing PaintRowGroupBackgroundByColIdx on aColIdx so we could avoid doing array stuff for the single-uint32 case, but that doesn't actually seem to affect things that much at first glance.
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #14) > Some numbers around my first bullet point: > > Clean local build: 93 tiles/sec > With bug 1409140 fixed: 105 tiles/sec > Also with bug 1409154 fixed: 145 tiles/sec > Also with bug 1409162 fixed: 159 tiles/sec > > I might be able to squeeze a bit more out of it, but really we need to fix > bug 1409114. Thanks Boris - that's a big improvement in a short time ~(65%), and if comparable to your previous numbers (probably is), then it puts us roughly on a par with Firefox 54's perf - though still taking about 4x the time as Chrome. It's unfortunate that retained display lists doesn't seem to help here - :miko, is this something that might change, or is worth evaluating?
Flags: needinfo?(mikokm)
I haven't looked too much at this yet, but it looks like it doesn't use border-collapse, so it seems plausible that retained display lists can help here. We'd need bug 1362412 to be fixed at the very least though.
(In reply to Randell Jesup [:jesup] from comment #7) > Also: just mousing over a link in the "results" box causes very slow > response; a quick profile shows 240ms blocks sitting 100% inside > PaintRowGroupBackgroundByCollIdx on each mouse-over-a-link-at-the-bottom. > https://perfht.ml/2xLMTfs Any thoughts why we're chewing all this time mousing over links? Perhaps it's to be expected for some reason, but it seems unnecessary.
Tried a quick hacky fix for 1362412 to test that theory out: Local build of the graphics branch + fix, retaining disabled: 81 tiles/sec Local build of the graphics branch + fix, retaining enabled: 241 tiles/sec So getting that fixed will be a pretty big win here.
Might be worth seeing how things perform for a "border-collapse:collapse" modification of the testcase, esp. one with some borders. > Any thoughts why we're chewing all this time mousing over links? Presumably it invalidates the table. Now why...
Depends on: 1362412
(In reply to Randell Jesup [:jesup] from comment #19) > (In reply to Randell Jesup [:jesup] from comment #7) > > Also: just mousing over a link in the "results" box causes very slow > > response; a quick profile shows 240ms blocks sitting 100% inside > > PaintRowGroupBackgroundByCollIdx on each mouse-over-a-link-at-the-bottom. > > https://perfht.ml/2xLMTfs > > Any thoughts why we're chewing all this time mousing over links? Perhaps > it's to be expected for some reason, but it seems unnecessary. PaintRowGroupBackgroundByColIdx means 'build display items for the row group background'. Without retained-dl, we always have to rebuild all visible display items when we paint, and that's pretty slow for this page.
Flags: needinfo?(mikokm)
(In reply to Matt Woodrow (:mattwoodrow) from comment #20) > Tried a quick hacky fix for 1362412 to test that theory out: > > Local build of the graphics branch + fix, retaining disabled: 81 tiles/sec > Local build of the graphics branch + fix, retaining enabled: 241 tiles/sec > > So getting that fixed will be a pretty big win here. Yes! Combine that with bz's fixes and we're in a lot better shape (though if we're not going down into these cases with d-l retaining, bz's fixes may not add to this in the normal case - not sure). I'd be pretty easy to check.
(In reply to Matt Woodrow (:mattwoodrow) from comment #22) > > Any thoughts why we're chewing all this time mousing over links? Perhaps > > it's to be expected for some reason, but it seems unnecessary. > > PaintRowGroupBackgroundByColIdx means 'build display items for the row group > background'. Without retained-dl, we always have to rebuild all visible > display items when we paint, and that's pretty slow for this page. Thanks - sounds like this part will be fixed by retained-dl. (When do we expect that to land? 59? 60? I know it was a priority) Also, the delay should be reduced by any work to speed up DL creation like the bugs bz filed.
> Thanks - sounds like this part will be fixed by retained-dl. Not unless bug 1362412 is fixed too.
Priority: -- → P3
Both RDL and bug 1362412 are fixed in Nightly. How does it look?
Flags: needinfo?(bugs) → needinfo?(mks)
209x100 (BIG) maze, they go slower!: FF 56: 413ms JS, 1760818 non-JS (>82ms/tile) (12/tiles/s!) Nightly local build: 370ms JS, 222762ms non-JS (10.8ms/tile) (92.7 tiles/s) Chrome 63 (209x102): 293ms JS, 91653ms non-JS (4.3ms/tile) (231/tiles/s) So a big improvement! though still not quite up to Chrome: From near 20x time to 2.6x time (of Chrome) Smaller maze: (100x58) 56: 121ms/32965ms - 5.7ms/tile 175 tiles/s nightly: 103/18183 - 3.15 ms/tile 318 tiles/s Chrome: 104/8736 - 1.5 ms/tile 656 tiles/s One smaller mazes, FF 56 does much better (not well); Chrome and Nightly keep pace with each other on smaller mazes (Nightly actually gains a bit on Chrome), from ~2.6x to 2x. JS time catches up to Chrome (though it's minor in the total here) I note that bug 1409114 is still open (mentioned by bz earlier). Having cleared out the micro-optimizations, and retained-DL, and bug 1362412, is that the next target? Will that get us on a par with Chrome? Also, we should see what other stumbling blocks remain.
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(bzbarsky)
Local Nightly build profile (209x100): https://perfht.ml/2qTF70j
In the Content process: 11% just in MergeDisplayLists() (from nsLayoutUtils::PaintFrame) nsLayoutUtils::PaintFrame() is called from 3 different stacks; one 25%, one 20%, and one 17% = 62% nsLayoutUtils::PaintFrame::BuildDisplayList() is 8/13/8 = 29% Between them it's 91% Also: I'm seeing 250-650ms event processing delays for that content process (11 tiles/step, which may be what actually causes the event delay).
Some things that stand out: * Building the hash table for merging takes a while - bug 1426044 should help here. * Merging event regions is slow, bug 1426277 is filed for that (but not assigned). * AssertDisplayItemData is slow - see bug 1331928 and bug 1377316. * In3DContextAndBackfaceIsHidden takes a while. We can cache this, but it might just be the cache hit of accessing the frame, and the time will move to the next thing that accesses the frame. * ComputeGeometryChangeForItem takes a while, even though we should be taking the early return (nothing changed) for most items. This might be just trashing the cache reading all the DisplayItemData objects in hashtable iteration order. * RecomputeVisibility takes 4x as long as actually painting. We recompute the visibility for every item in the PaintedLayer (to account for the invalid region, and occlusion), and do this every paint even though barely anything changed. There should be a way to avoid repeating all this work. Some long hanging fruit there, and some that will take a bit more work. Not sure if we'd quite catch chrome with that, but it'd be closer again.
Flags: needinfo?(matt.woodrow)
Running this test case with gfx.webrender.enabled=true and gfx.webrender.hit-test=true is a lot faster for me than trunk: Trunk: Maze Complete (Table) [Firefox 59] Maze size: 103 x 54 (5562 tiles) 87 ms in JavaScript 0.015 ms/tile 16661 ms not in JavaScript 2.995 ms/tile 16748 ms total time 3.011 ms/tile 332.09 tiles per second 11 tiles/step https://perfht.ml/2ms4Ece vs WebRender: Maze Complete (Table) [Firefox 59] Maze size: 103 x 54 (5562 tiles) 105 ms in JavaScript 0.018 ms/tile 9790 ms not in JavaScript 1.76 ms/tile 9895 ms total time 1.779 ms/tile 562.1 tiles per second 11 tiles/ste https://perfht.ml/2mt0DUQ Also, fixing bug 1425863 will probably further improve the WebRender times.
> I note that bug 1409114 is still open (mentioned by bz earlier)... is that the next target? Looking at the profile linked in comment 28, I see the following (in Content (2 of 2)): * Total time under BuildDisplayListForStackingContext is about 952ms. * Total time under PaintRowGroupBackgroundByColIdx is about 675ms (included in the 952ms number, I believe). * Total time under PaintFrame is 15,677ms (includes the 952ms number above). So fixing bug 1409114 can't help by more than about 6% at this point, afaict...
Flags: needinfo?(bzbarsky)
So, I love the improvements - I have yet to get a nightly build on my Mac but I have the latest beta build (58.0b16) On this machine, compared to Chrome and Safari: I set the browsers to have the same window size (thus maze size) and ran the table benchmark variant, using the restart button to run it twice before taking the measurement. Nothing else running on the machine other than the OS itself. Maze Complete (Table) [Firefox 58] Maze size: 114 x 74 (8436 tiles) 96 ms in JavaScript 0.011 ms/tile 72084 ms not in JavaScript 8.544 ms/tile 72180 ms total time 8.556 ms/tile 116.87 tiles per second 11 tiles/step Maze Complete (Table) [Chrome 64] Maze size: 114 x 74 (8436 tiles) 111 ms in JavaScript 0.013 ms/tile 13263 ms not in JavaScript 1.572 ms/tile 13374 ms total time 1.585 ms/tile 630.77 tiles per second 11 tiles/step Maze Complete (Table) [Safari 11] Maze size: 114 x 74 (8436 tiles) 64 ms in JavaScript 0.007 ms/tile 7156 ms not in JavaScript 0.848 ms/tile 7220 ms total time 0.855 ms/tile 1168.42 tiles per second 11 tiles/step Note the 10x difference in overall performance. The amazing thing is I tried it on my iPhone 6s (2+ year old iPhone) - it does not have the same layout and I can't really control it to change it but it was actually larger: Maze Complete (Table) [Safari 11] Maze size: 78 x 116 (9048 tiles) 176 ms in JavaScript 0.019 ms/tile 5426 ms not in JavaScript 0.599 ms/tile 5602 ms total time 0.619 ms/tile 1615.13 tiles per second 11 tiles/step This is amazing since my laptop is a very fast quad-core i7 with tons of cache and yet the iPhone beat it! My guess is that the rendering engine is much more optimized (time not in JS) but the browser is, I am sure, very similar in software. (They both show up as Safari 11 in the UA string) PS - I don't have the screen space to get to the same layout as the iPhone (or even 90 degree rotated) but I figure this is basically equivalent.
Flags: needinfo?(mks)
On current Nightly, I get: Maze Complete (Table) [Firefox 61] Maze size: 157 x 77 (12089 tiles) 235 ms in JavaScript 0.019 ms/tile 47904 ms not in JavaScript 3.962 ms/tile 48139 ms total time 3.982 ms/tile 251.12 tiles per second Chrome 65: Maze Complete (Table) [Chrome 65] Maze size: 157 x 77 (12089 tiles) 167 ms in JavaScript 0.013 ms/tile 34360 ms not in JavaScript 2.842 ms/tile 34527 ms total time 2.856 ms/tile 350.13 tiles per second Edge 16.16299 (kinda funny that it gets identified as Chrome 58...): Maze Complete (Table) [Chrome 58] Maze size: 157 x 76 (11932 tiles) 530 ms in JavaScript 0.044 ms/tile 36727 ms not in JavaScript 3.078 ms/tile 37257 ms total time 3.122 ms/tile 320.26 tiles per second Looks like there's still room for improvement, but still be better from the 60-65 I measured on the same system back in comment 8.
status-firefox59: affected → wontfix
status-firefox60: affected → wontfix
status-firefox61: --- → affected
Can you try with WebRender turned on?
Flags: needinfo?(ryanvm)
Maze Complete (Table) [Firefox 61] Maze size: 157 x 77 (12089 tiles) 235 ms in JavaScript 0.019 ms/tile 38259 ms not in JavaScript 3.164 ms/tile 38494 ms total time 3.184 ms/tile 314.04 tiles per second
Flags: needinfo?(ryanvm)
Depends on: 1446667
Depends on: 1467514
Performance Impact: --- → ?
Whiteboard: qf:?
No longer blocks: 929484
Regressed by: 929484

Set release status flags based on info from the regressing bug 929484

status-firefox100: --- → affected
status-firefox98: --- → affected
status-firefox99: --- → affected
status-firefox-esr91: --- → affected

I suspect this is no longer an issue. Running this locally I see Firefox out performing Chrome:

Chrome v101: 644.05 tiles/second
Firefox v101: 1034.13 tiles/second

Time in JavaScript:
Chrome v101: 0.008 ms/tile
Firefox v101: 0.009 ms/tile

Time not in JavaScript:
Chrome v101: 1.543 ms/tile
Firefox v101: 0.957 ms/tile

Performance Impact: ? → P2
Keywords: perf:pageload

Redirect a needinfo that is pending on an inactive user to the triage owner.
:dholbert, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(milaninbugzilla) → needinfo?(dholbert)

I agree, the regression is basically resolved but somehow my high end PC running Firefox is slower (by a major factor) then my old iPhone 11 running this.

The high end, 3.2GHz Intel Xeon 2-socket, 8-cores per socket PC with Firefox 100.0.2:
78x134 maze size: total: 2.165 ms/tile : not-JS 2.147 ms/tile : JS 0.018 ms/tile

Same PC with Microsoft Edge version 101.0.1210.53:
78x134 maze size: total: 4.498 ms/tile : not-JS 4.514 ms/tile : JS 0.015 ms/tile

The iPhone 11 pro with standard browser (Safari)
78x134 maze size: total: 0.506 ms/tile : not-JS 0.496 ms/tile : JS 0.009 ms/tile

It is important to actually use the same maze size as the performance is not exactly linear with size.

This is with the fixed seed (so the benchmark mode)

It is great seeing Firefox twice the performance as Edge (which is based on Chromium)
It is sad to see that there is over 5x performance difference between the very powerful desktop machine and the nearly 3-year old iPhone.

(In reply to Michael Sinz from comment #40)

It is great seeing Firefox twice the performance as Edge (which is based on Chromium)

Resolving as WORKSFORME given that we're substantially better than the competition, in an apples-to-apples comparison (same hardware).

It is sad to see that there is over 5x performance difference between the very powerful desktop machine and the nearly 3-year old iPhone.

This would be interesting to investigate further, though it's hard to really draw any conclusions from, given the different OS/chipset/devicePixelRatio/etc.

(One thing to keep in mind: your desktop's "2-socket, 8-cores per socket" superpowers don't help at all on this single-page benchmark, since generally a website only has access to a single core [unless it's using worker threads].)

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(dholbert)
Resolution: --- → WORKSFORME

Believe me, I understand the many cores do not help the browser directly, but it helps in that the browser gets the full CPU core to itself and all other operations were the same.

As far as pixel ratio - the way I have the page set up, the number of pixels per cell are logically as I have the page do device resolution and my desktop is 1:1 in Windows. (I can show you similar results on the Mac, just don't have it here in the office.)

There was a time that the Firefox/Mozilla browser was under 2ms per tile at this size maze. But that was a very long time ago. Back then, the IE browser was in the crazy hundreds of ms per tile score (it was also all on older PC hardware, so the 2ms per tile was much more impressive)

When I get a chance, I will try this on my MacBookPro with its Core-i9 CPUs.

On the same machine - Late 2019 MacBookPro 16 BTO: Again, it is great that the regression in FireFox has been fixed. It had real impacts elsewhere.

Maze Complete   (Table)   [Firefox 99]
Maze size: 125 x 85 (10625 tiles)
94 	ms in JavaScript 	0.008 	ms/tile
10168 	ms not in JavaScript 	0.956 	ms/tile
10262 	ms total time 	0.965 	ms/tile
1035.37 	tiles per second 	11 	tiles/step

Maze Complete   (Table)   [Safari 15.4]
Maze size: 125 x 85 (10625 tiles)
84	ms in JavaScript	0.007	ms/tile
6571	ms not in JavaScript	0.618	ms/tile
6655	ms total time	0.626	ms/tile
1596.54	tiles per second	11	tiles/step

So we're still about 50% slower than safari on an x86 macbookpro

I imagine there are still some pending improvements like "* AssertDisplayItemData is slow - see bug 1331928 and bug 1377316."

As for Safari on iOS; sometimes people take shortcuts or take advantage of skipping some things due to the platform they're on. Hard to say without ability to look more closely at comparative profiles or the like (tough on a iPhone)

Duplicate of this bug: 626927
Duplicate of this bug: 1306052
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: