1849956 - silver.urih.com - Extremely slow performance

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Calin Tanase]

From github: https://github.com/webcompat/web-bugs/issues/126064.

Note: Feel free to move the issue if the Product/Component is wrong

<!-- @browser: Firefox 116.0 -->
<!-- @ua_header: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 -->
<!-- @reported_with: unknown -->

URL: https://silver.urih.com/

Browser / Version: Firefox 116.0
Operating System: Linux
Tested Another Browser: Yes Chrome

Problem type: Something else
Description: benchmark scores are extremely slow compared to chromium
Steps to Reproduce:
I'm filing this because it seems like there might be some pretty interesting performance improvements hiding in the disparity between chromium and firefox for this particular benchmark. Typically I see small performance diffs for raw benchmarks between FF and chromium but in this case the difference is pretty extreme (almost 100x slower).

To test just visit https://silver.urih.com/ and click the big "Benchmark" button. Note that it will use navigator.hardwareConcurrency for the size of the thread pool, so if comparing browsers make sure they are reporting the same number or use an Object.defineProperty override in devtools to ensure comparisons are 1:1.

Some other observations:
My CPU gets nowhere near it's thermal limits when running this. 70c out of 95c
CPU bounces between 60% and 100% in bursts. This is somewhat on the benchmark tool, but the spats of 60% do not happen when running on chromium.
<details>
<summary>View the screenshot</summary>
<img alt="Screenshot" src="https://webcompat.com/uploads/2023/8/831c64fa-f25f-429c-8631-d141d32ec035.jpg">
</details>

<details>
<summary>Browser Configuration</summary>
<ul>
<li>None</li>
</ul>
</details>

From webcompat.com with ❤️

Change performed by the Move to Bugzilla add-on.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 2

[Alice0775 White]

I can reproduce the performance issue on Nightly118.0a1 Windows10.
Profiler: https://share.firefox.dev/3KQjxQI

Comment 3

[Mayank Bansal]

Here is a Chrome profile if it is useful : https://share.firefox.dev/3shshZG

Comment 5

[Iain Ireland [:iain]]

I took a quick look at a profile. We have a bunch of worker threads, each of which is spending 85% of its time under GetIterator. Specifically, the culprit seems to be this function:

Il9.prototype.W = function (a) {
  var b = Il0,
  c;
  for (c in this.c) {
    var d = this.c[Number(c)].W(a);
    d !== Il0 &&
    d.t < b.t &&
    (b = d)
  }
  return b
};

This function is repeatedly doing for-in enumeration over an array of length 9 to get a set of string keys, then immediately converting those back to numbers to use as array indices. I have no idea why anybody would ever choose to write this code, let alone in the middle of what is purportedly a "photon mapping rendering engine".

We don't support caching iterators with elements, so we end up allocating a fresh iterator each time. Because this is being done in a bunch of worker threads simultaneously, we end up with a lot of lock contention in jemalloc.

We have bug 1502905 to track caching iterators with dense elements. Jan and I talked about it this morning, and we've come up with a design that might work. I'll write it up in that bug.