1552356 - CSS Named Color "hue vs luminosity" chart demo is much slower in Firefox than in Chrome (with time spent in JS math code)

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine: JIT, task, P3)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Load https://comfortable-weeder.glitch.me/ in side-by-side Firefox vs. Chrome
2. See how long it takes the animation to complete (filling out the whole color diamond) in each browser.

ACTUAL RESULTS:
Chrome takes ~10 seconds.
Firefox takes ~50 seconds.

EXPECTED RESULTS: we should be on par.

Here's a profile of Nightly for the first ~15 seconds of this load (during which time Chrome easily finishes the whole thing):
https://perfht.ml/30r8956

We're spending 50% of our time in the JS engine calling fdlibm::sqrt (called by fdlibm::hypot), as shown in this invert-stack view:
https://perfht.ml/30mqWi1

Comment 1

[Daniel Holbert [:dholbert]]

Note: this demo's author (Tab Atkins) is currently messing with it a bit, so it doesn't load anything interesting at all right now. He promises not to make it faster, though :) (per twitter thread at https://twitter.com/CodingExon/status/1129145052708519936 )

Anyway, hopefully it'll be back up and testable in time for whenever someone can take a look at this.

Comment 2

[Nicolas B. Pierron [:nbp]]

The problem is that the rasterize function is an async function, and that SpiderMonkey does not yet compile Generator / Async-functions with its optimizing JIT.

Moving the inner loop which loops over x in a separated function should improve by optimizing this inner function with the optimizing JIT and relying on the ecmaHypot function.

Comment 3

[Gregory Pappas [:gregp]]

This demo seems to run better these days. Daniel, what do you think?
https://share.firefox.dev/3WoZInu

Comment 4

[Daniel Holbert [:dholbert]]

Indeed it does! I just tested and Firefox seemed to be slightly faster than Chrome, actually. I'm guessing the "SpiderMonkey does not yet..." note from comment 2 has since been addressed.

Comment 5

[Daniel Holbert [:dholbert]]

I ran mozregression to find the fix range. In old builds (e.g. comment 0's datestamp) I'm not seeing anything as bad as the 50-second time that I mentioned in comment 0 -- I'm seeing something like 5-6 seconds in newer builds, maybe 6-7 seconds in Chrome, vs. 8-12 seconds in older Firefox builds (with noticeably smaller progression per frame towards the end).

But that was still enough to find a fix range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b47dc08fc77ad2f26cee89a216c333ff490d195f&tochange=c6d819bd39daf86acd5e0c5bce5d74c2db8b8d64

That includes bug 1682623 "Enable Warp Compiled Generators and Async Functions", which sounds like it'd be what fixed this, based on comment 2.