1872702 - https://perftest.netlify.app/stylebench/ significant slower on windows

Status: UNCONFIRMED

(Core :: Performance: General, enhancement)

Description

[André Schubert]

Attachment: about-support-raw.json

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0

Steps to reproduce:

Recently i wondered why Firefox feels so much faster running on Linux compared to the same Computer running Windows.
I've benchmarked Firefox on both OS with https://perftest.netlify.app/stylebench/ and found out, that the same Benchmark runs around twice as fast on Linux.

I'm very interested why firefox is (or at least feels) so much faster on Linux instead of windows.
By accident i have found a way to get similar results in the benchmark (and maybe regarding overall performance on other sites?). I realy don't have a clue why this is happening, but here is how i achieved the performance boost:

1. Use Firefox on Microsoft Windows (tested with both Windows 10 and 11).
2. Go to https://perftest.netlify.app/stylebench/ and run the benchmark.
3. Take a look at the benchmark result (for comparison afterwards).
4. Open the Firefox Devtools.
5. Start the Profiler with settings preset "Graphics".
6. While die Profiler is recording, re-run the Benchmark.
7. The benchmark runs significant faster and results in higher score.

Maybe somebody can explain to me, why the benchmark runs faster while profiling the grahpics.
Or maybe there is an easy fix for that, which makes firefox faster on many other websites.

I also attached the about:support content from my Firefox (on Windows)

Comment 1

[Justin Link]

If a feature is faster (on Windows) when the profiler is enabled that is a strong sign that the performance of that feature is sensitive to the timer resolution. The profiler increases the timer resolution on Windows to allow it to collect frequent samples, and a side effect of this is that all timer-related activities (such as checking to see if it's time to wake up the TimerThread so that it can check to see if any timers are ready to fire) also happen more frequently.

With https://bugzilla.mozilla.org/show_bug.cgi?id=1826224 there is now functionality for Firefox to automatically request high-resolution timers for foreground processes when not on battery power. This functionality is controlled by a pref (timer.auto_increase_timer_resolution) that defaults to "off" outside of Nightly.

Trying this benchmark locally with and without that pref enabled I do see a dramatic increase myself - from 69 without to 114 with.

So that explains why the benchmark shows such a dramatic difference when the profiler is running.

@Andre: You mention that you've felt that Firefox feels much slower on Windows than on Linux, even on the same machine. Would you mind trying out enabling the above-mentioned pref (you can find it by going to about:config and searching for "timer.a") and seeing if it feels to you like that gap is closer with it enabled?

Comment 2

[André Schubert]

Thank you Justin for the explanation!

Enabling the pref does affect the benchmark score. Now it increases from 85 to 135. I think on linux it's still a bit higher, but thats not the point of this ticket.

With "much slower" i mean much slower in the benchmark, not "much" slower on all websites :-)
I will turn on the pref on my personal tower pc / notebook at work (I'm basically a web dev) and keep an eye on this the next couple of days and weeks.

I really have to say thank you to all of you at mozilla. I have not expected an answer to this topic in such a short time. Thank you! :-)

For now, all my questions are answered. So because of the fact that you are already have "timer.auto_increase_timer_resolution" to adress this problem, this ticket can be closed. Or do you need more information from me?

Comment 3

[Justin Link]

Thank you for the kind words!

I don't think we need any more information however, since you seem willing to try running with this pref enabled, if you come across anything interesting while doing that, would you mind putting a comment with your observation on https://bugzilla.mozilla.org/show_bug.cgi?id=1872786)? We'd be interested in any data points that would help us make the decision to enable that feature more broadly or to alert us to any problems that we could look and resolve before it is rolled out.

Comment 4

[Bas Schouten (:bas.schouten)]

No impact set since this report affects a benchmark.