1814806 - Demo (https://www.fxhash.xyz/generative/21866) loads slower in Nightly compared to Chrome

Status: RESOLVED WONTFIX

(Core :: JavaScript: WebAssembly, enhancement, P3)

Description

[Mayank Bansal]

Go to https://www.fxhash.xyz/generative/21866 (Exact hash is used was https://gateway.fxhash2.xyz/ipfs/QmPQKuoX1idieCm2jQpCE9XBinZafYFJpj46dBJqSGL113/?fxhash=ooXr5suon2ty4W8m7QUjoTDPvUQRqndxbiu5eTUqiYpCRRfwgjE)

Nightly: https://share.firefox.dev/3Huw1uL (4.8 econds)
Chrome: https://share.firefox.dev/40kYDzv (~3 seconds)

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[Julien Pages [:jpages]]

I finally looked at these profiles.

The main function doing the rendering is $func193, this one is calling two other very important functions: $func20 and $func384.
Most of the difference is coming from these two functions. $func20 is calling the second one $func384.
FF is slower than Chrome by 1 sec in these functions.

It's interesting because $func384 is a leaf function and it's much slower in FF than Chrome: time is 1849 ms vs 741 ms.
$func384 is not doing anything fancy: it's quite short and mostly loops and variable accesses.

It's worth noting that there is a promise callback handling all of that, which might explain the difference as well.

I have attached the .wat file.

Comment 3

[Julien Pages [:jpages]]

Attachment: func384.wat

Comment 4

[Julien Pages [:jpages]]

Attachment: ion_code.txt

Comment 5

[Julien Pages [:jpages]]

Attachment: baseline_code.txt

Comment 6

[Julien Pages [:jpages]]

Forcing the optimizing compiler (ion) for this benchmark gives much better results, very close to Chrome (about 3 seconds in total).

Looking at the generated code with both compiler, I think the issue might be around the poor register allocation with baseline.
In the top function, everything ends up on the stack with baseline, with ion, the register allocation is better. The main big difference between baseline and ion is removing all those stack accesses. It also simplifies and shortens the code by not accessing the stack.

This looks like a tiering issue which we can't really fix at the moment... Once the optimizing compiler has done its magic, the results are actually very close to Chrome.