1857495 - setTimeout inconsistent and very inaccurate

Status: RESOLVED DUPLICATE of bug 1838761

(Core :: DOM: Core & HTML, defect)

Description

[poyev49418]

Attachment: test-settimeout.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

Go to test html file. Press button and wait until result is printed on screen and then press button again, repeat 20 times. Test sets timeout to 1500ms and highlights times that are > 30ms plus.

Actual results:

Timing is very inconsistent, and sometimes notably bad where the extra delay is more than 170ms!!
Screenshots are from Ubuntu 22.04, but did a quick check on Android with the Nightly 120 build, and it shows the same or similar inconsistency (got a time of 1610ms).

Expected results:

Expected result would be much closer to the set time and within a span of 0-20ms plus as a tolerance, but closer to zero is obviously better.

Compared with Chrome (screenshot) it is extremely bad. What will be the intended use case for setTimeout if you can't use it for setting a more accurate time? This is way beyond acceptable. On webkit (iOS) as well you don't see this. So i file this as a defect as I have a hard time seeing this as the intended outcome from your side.

Comment 1

[poyev49418]

Attachment: Firefox_on_Ubuntu22_Trial-1.png

Comment 2

[poyev49418]

Attachment: Firefox_on_Ubuntu22_Trial-2.png

Comment 3

[poyev49418]

Attachment: Chrome_on_Ubuntu22.04.png

Comment 4

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

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 5

[Mayank Bansal]

On windows, if I enable the gecko profiler, the setTimeouts become very consistent.

Comment 6

[poyev49418]

Don't know if it helps but here is my profiler upload: https://share.firefox.dev/3PLxAJ4

Running a test of 10 times on ubuntu with results as follow. However, I first managed to do the test 20 times and it was consistently alright. But then as below, where 1, 5 and 10 is well above expected levels.
1659
1499
1500
1501
1576
1501
1500
1501
1501
1596

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Timers aren't really supposed to be very accurate and browsers may optimize power usage by trying wake up threads only at certain points.
Does tweaking timer.maximum_firing_delay_tolerance_ms affect the behavior here?

Comment 8

[yerax39337]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #7)

Timers aren't really supposed to be very accurate and browsers may optimize power usage by trying wake up threads only at certain points.

Of course you can handle setTimeout anyway you want. Making it bad enough and loads of web pages and apps will be affected whether you think they are using setTimeout “the right way” or not. I mean average Joe out there doesn't care about benchmarks if things look bad on the screen in front of him, or stuff doesn't work. Optimizing CPU-usage by reducing functionality, isn’t the way to attract users. And setTimeout needs to be functional for developers too, i.e. somewhat consistent and somewhat accurate, cross-browsers and over time. It would be great if a “low precision” timer could be opted for if your app doesn’t need any higher precision timer to reduce CPU-usage, but turning setTimeout into that without an option for developers, is just making it bad for everyone. There is no denying setTimeout is very practical in many cases, so it is better to keep it that way.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Btw, it is a bit hard to understand what the test is doing. When I click the button 25 times on Chrome, I get
17.80000001192093
42.69999998807907
43.69999998807907
28.900000035762787
14.899999976158142
15.600000023841858
13.900000035762787
6.400000035762787
21.80000001192093
14.100000023841858
8.100000023841858
147.9000000357628
142.4000000357628
107.5
268.39999997615814
141
109.30000001192093
262.10000002384186
400.80000001192093
555
709.1000000238419
866.7000000476837
1047.7000000476837
1320.2000000476837
1500.800000011921

I don't know what is expected?
I get very similar numbers in Firefox

Comment 10

[Peter Van der Beken [:peterv]]

Result on Safari:
1501
1501.000000000001
34
34
134
283
303
268
219
264.9999999999982
318
1
369.0000000000018
331
317
301
304
332
366.0000000000018
368
287
51
466
915
1500

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

smaug, peterv: it seems that you click the button before the result appears.

I got consistent result on Windows both Firefox and Chrome. It seems that it depends on what's done in the background and how much steal the resource from the others.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Oh, if I need to always wait, then I get consistent behavior on linux, on Nightly.