1942338 - Nightly is 1.2x slower on an online demo https://matrix.reshish.com/multiplication.php (This is not a slow matrix multiplication bug)

Status: RESOLVED INVALID

(Core :: JavaScript Engine, task, P5)

Description

[Mayank Bansal]

This bug is not about slow matrix multiplication

Go to https://matrix.reshish.com/multiplication.php
Set the matrices to 15x15 if not already set
Click on "Set Matrices"
Let the empty matrices generate.
Click on "Fill empty cell with zeros", and then enter any number in the first cell.
Do this for both the matrices.
Click on Calculate button
Wait for the calculation to complete
Once the Result Matrix appears, click on the "Show Solution" button. This is the step that we are testing here

Nightly: https://share.firefox.dev/42fDMRh (16s)
Chrome: https://share.firefox.dev/3WjLear (13s)

We are not terribly slow here, but is there anything obvious to improve?
The 2.5s time around GC from 22s onwards may also be interesting to see.

Comment 1

[Mayank Bansal]

Attachment: 15x15 matrix random values

Comment 2

[Mayank Bansal]

Attachment: bandicam 2025-01-17 22-21-12-716.mp4

Comment 3

[Iain Ireland [:iain]]

I don't see anything obviously actionable here. It looks like this code is making a lot of garbage: if I'm reading this profile correctly, there are ~1900 minor GCs over the course of 4 seconds around the 13-17 second mark, all of which are OUT_OF_NURSERY with extremely low tenure rates (~0.1%). We're spending ~25% of our time in GC, compared to V8 spending ~15%. On the other hand, it's not obvious that GC is the primary problem here: if I subtract all the GC time from both profiles, we're at ~12.8 vs 11.2 seconds, so matching V8's GC performance would still leave us ~15% slower.

One vaguely interesting observation is that the hottest functions in the measured section for V8 are pe (chunk-D8qU7Cuo.js:2:428) and z (chunk-D8qU7Cuo.js:2:305), adding up to ~8% of samples. Filtering on chunk-D8qU7Cuo.js:2, I don't see a single sample in those functions for Firefox. So it's possible that we're somehow going down a different code path. But this is all minified to within an inch of its life, so it's painful to investigate further.

My instinct is that the gap here is not big enough to justify more investigation.

Comment 4

[Mayank Bansal]

Thanks Iain for the detailed investigation!
I am tempted to close this as INVALID