Open Bug 1898545 Opened 1 month ago Updated 1 month ago

Bryntum Components are 3.5x+ slower in Firefox than Chrome.

Categories

(Core :: JavaScript Engine, defect, P3)

defect

Tracking

()

People

(Reporter: mgaudet, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

The below is copy pasted from some comments in Bug 1317690, as this is a better venue for this discussion

Bug 1317690 Comment #17

To examine things on real website, please do the following:

  1. Open the https://bryntum.com/products/gantt/examples/bigdataset/ page. (If you'd like to check other examples, see https://bryntum.com/products/gantt/examples/)
    2. In console, type: window.DEBUG = true
    3. Click the "5K Tasks" button in the top toolbar. This will switch the example gantt to a new dataset of 5K tasks.

You should see the following output in console:

For Chrome:

window.DEBUG = true
true
generate: 25.85107421875 ms
Initializing project
Populating project: 887.9541015625 ms
Time to visible: 5474.97509765625 ms
Finalize propagation: 708.40185546875 ms

For Firefox:

window.DEBUG = true
true
generate: 303ms - timer ended
Initializing project
Populating project: 18714ms - timer ended 
Time to visible: 168067ms - timer ended 
Finalize propagation: 21519ms - timer ended

What happens here is:

  • generate - the example data is generated. Generation uses generators, perhaps that explains the 10x slowdown compared to Chrome, however, this is not a primary metric we are interested in.
  • Populating project - example data is loaded into "reactive graph". This does not involve generators, but instantiates lots of small objects (like hundreds of thousands of them). 21x slowdown compared to Chrome, would be great to see it optimized to be comparable.
  • Time to visible - this metric is the topic of this issue. Here the "reactive graph" calculates the final state. 30x slowdown compared to Chrome. Calculations are generators-based. During calculations, it also allocates the edges in the graph (populates lots of Map instances).
    Finalize propagation - not related to generators, 30x slowdown.

Hopefully the numbers are self-explanatory, if you need any other information and/or benchmark, please let me know.

Probably one need to optimize the allocation speed too, because the most important metric Time to visible is a combination of generator calls + allocation. In particular, the allocation of Maps, and internal allocations by Maps. I'll open a new ticket for that.

Bug 1317690 Comment #17

Just opening https://bryntum.com/products/gantt/examples/bigdataset/
Nightly: https://share.firefox.dev/4b9raNf (3s)
Chrome: https://share.firefox.dev/4bb4Umm (1.8s)

Clicking on 5K
Nightly: https://share.firefox.dev/3UQdzVo (12s)
Chrome: https://share.firefox.dev/3WPzMVd (3.5s)

With window.DEBUG = true , I generally get 11s with Firefox. But one time, Firefox took 45s.

Severity: -- → S3
Priority: -- → P3

(One oddity looking at the Chrome vs Nightly profiles: The Chrome ones have what seem like real function names (Transaction2, etc), whereas the firefox one seems minified -- so it's not clear we're even running the same code as Chrome here)

Depends on: 1851662

Markus: Would you be able to generate a comparison report on this site? (Sort of curious if your tooling can take something odd like this too :) )

Flags: needinfo?(mstange.moz)

Hmm.

The page seems to be performing appreciably better for me now. Still a fair amount of jank and stutter, but where it was previously unusable, now it's just bad. Here's a new profile: https://share.firefox.dev/4bNMHuJ

I did two things:

  1. Caught up on a few nightly updates -- I was out of date by ~week
  2. Hard refreshed the site. Maybe I had an older version of this?

Mayank: You had previously reproduced slowness -- do you see it still?

(Thanks for the profiles by the way!)

Flags: needinfo?(mayankleoboy1)

A Release profile: https://share.firefox.dev/3Vd4jLj

Chrome window.DEBUG=1 numbers for 5K tasks

Populating project: 195.7890625 ms
Time to visible: 1257.27001953125 ms
Finalize propagation: 181.125 ms

Firefox window.DEBUG=1 numbers for 5K tasks

Populating project: 1127ms
Time to visible: 4800ms
Finalize propagation: 1113ms

So - Chrome is faster by

  • 5x for Populating Project
  • 3.8x for Time to Visible
  • 6x for Finalize Propagation.

(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #2)

Markus: Would you be able to generate a comparison report on this site? (Sort of curious if your tooling can take something odd like this too :) )

Report: https://github.com/jrmuizel/js-profile-compare/blob/main/reports/Bryntum-BrowserWin-May23.md
It seems to have worked ok except for the source code extraction. I wouldn't believe any of the source code that's displayed inline in the report.
You can get the actual start offsets of each compared function in the last column of the comparison table at the top.

Flags: needinfo?(mstange.moz)

(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #3)

Mayank: You had previously reproduced slowness -- do you see it still?

Just opening https://bryntum.com/products/gantt/examples/bigdataset/ : https://share.firefox.dev/4bTp4kr / https://share.firefox.dev/3UTfyHs (~3s)
Clicking on 5k : https://share.firefox.dev/3USpeSA (~12s)

These numbers are consistent with what i posted in https://bugzilla.mozilla.org/show_bug.cgi?id=1317690#c18

Flags: needinfo?(mayankleoboy1)
You need to log in before you can comment on or make changes to this bug.