The following code prints different result between Firefox and Chrome
var start = Date.now()
var id = setInterval(function interval() {
var whileStart = Date.now()
console.log(whileStart - start)
while (Date.now() - whileStart < 250) {
}
}, 100)
setTimeout(function timeout() {
clearInterval(id)
console.log('timeout',Date.now() - start)
}, 400)
chrome 74 print:
100
351
605
timeout 855
firefox 67 print:
101
351
timeout 601
why?
add setTimeout delay, the result is still different.
var start = Date.now()
var id = setInterval(function interval() {
var whileStart = Date.now()
console.log(whileStart - start)
while (Date.now() - whileStart < 250) {
}
}, 100)
setTimeout(function timeout() {
clearInterval(id)
console.log('timeout',Date.now() - start)
}, 500)
setTimeout queues your request to be handled at the first opportunity after the specified delay. Once the delay has elapsed and the call stack is empty your request is handled. This means there can be slight variations in the timing depending on what else the browser’s engine has going on.
That's because Chrome's implementation of setInterval does correct the drift between each call.
So instead of blindly calling again setTimeout(fn, 250) at the end of the interval's callback, it actually does setTimeout(fn, max(now - 250, 0)).
So this gives
t Firefox (no drift control) | Chrome (drift control)
––––––––––––––––––––––––––––––––––––––––––––––––––––––––
0 schedule interval #100ms schedule interval #100ms
0 schedule timeout #400ms schedule timeout #400ms
100 exec interval callback exec interval callback
=> block 250ms => block 250ms
... ...
350 schedule interval #450ms schedule interval #350ms
(now + 100ms) (now + max(100ms - 250ms, 0))
350 exec interval callback
=> block 250ms
400 exec timeout callback ...
=> cancel interval ...
...
600 schedule interval #600ms
exec interval callback
=> block 250ms
...
850 schedule interval #850ms
exec timeout callback
=> cancel interval
Note that the last interval #600 is actually dependent on which of timeout or interval as been scheduled first.
And also note that Chrome's behavior may become the standard in a near future: https://github.com/whatwg/html/issues/3151
The difference arises because of code differences between the two browsers.
If you reverse the order of starting the interval and timeout timers, Chrome behaves the same as Firefox:
"use strict";
var start = Date.now()
setTimeout(function timeout() { // start the timeout first
clearInterval(id)
console.log('timeout',Date.now() - start)
}, 400)
var id = setInterval(function interval() {
var whileStart = Date.now()
console.log(whileStart - start)
while (Date.now() - whileStart < 250) {
}
}, 100)
If you keep the same order as in the post but reduce the blocking to, say, 50 milliseconds, the interval time gets called at the 400ms mark in Chrome and blocks the timeout being called while it blocks the event loop. But in Firefox the setTimeout for 400ms gets called first, clears the interval timer and prevents the interval timer being called at all at the 400ms mark.
In short, timeout processing for intervals and timers is coded differently in the two browsers, and in case 2 above, Firefox appears to add 10ms to the interval between interval-timer calls (as allowed in Section 7.5 of HTML 5.2).
Related
When I run this code in Firefox and Chrome, the results are different:
function run() {
setTimeout(() => console.log("1"), 0);
setTimeout(() => console.log("2"), 100);
let start = Date.now();
while (Date.now() - start < 200) {
// do nothing
}
setTimeout(() => {
console.log("3");
}, 0);
start = Date.now();
while (Date.now() - start < 200) {
// do nothing
}
setTimeout(() => {
console.log("4");
}, 0);
}
run();
In Chrome (and Node.js), this is printed:
1
3
2
4
In Firefox, this is printed:
1
2
3
4
But if I remove the line 2 (setTimeout(() => console.log("1"), 0);), then the same thing is printed on every platform:
2
3
4
How to explain these different results?
Thanks!
The explanation: It doesn't matter.
The details of when deferred "messages" are added to the event loop message queue are implementation details, not documented guarantees. By the time your function yields control back to the event loop, all of your setTimeout call are eligible to execute (three of them were scheduled to run immediately, one of them was scheduled to run in 100 ms) and you've guaranteed it's been at least 400 ms since you scheduled it.
The difference between the two could be as simple as whether they choose to look for deferred tasks that have become ready (to move from the deferred queue to the main "ready to go" message queue) immediately before or immediately after new items are inserted in the main message queue. Chrome chooses to move immediately after 3 is scheduled (so 3 goes in, then the deferred 2), Firefox immediately before (moving in 2 before it puts 3 in).
Both of them could change in the next release without violating any documented guarantees. Don't rely on it, don't expect it to be stable. While immediately scheduled tasks are guaranteed to execute in FIFO order, there are no guarantees on when deferred tasks get moved onto the "ready-to-go" message queue. The spec seems to requires that 1, 3 and 4 execute in that order (since they were all immediately ready, not deferred), with only the ordering of 2 being flexible, but even that isn't a true guarantee; it can get weird with the various ways in which an "immediate" setTimeout task may not actually be scheduled immediately.
You may be interested in the MDN docs on why setTimeout can take longer than expected; it explains by side-effect a lot of how the event loop works, even as it carefully provides no guarantees on the details you're exploring.
I can't give you an full detailed explanation, but the second paramter of setTimeoput and setInterval doesn't mean, it will exactly execute it at that time. They will put it in a queue, so the background can execute it.
The browser has a lifecycle when to execute specific steps to update the data and the styles.
I can only send you this youtube link, that helped me to learn more about it:
https://www.youtube.com/watch?v=MCi6AZMkxcU
1, 2, 3, 4 is the behavior that is expected.
The specs ask to
Wait until any invocations of this algorithm that had the same global and orderingIdentifier, that started before this one, and whose milliseconds is equal to or less than this one's, have completed.
So any call to setTimeout that were both made before, and had their milliseconds set to a lower value should be called first.
Firefox, Safari, and the current stable channel of Chrome all do this.
So when the event loop gains control again, it sees that all the timers are ready to be called, and it queues tasks for each, in this scheduled called order:
"1": scheduled-time = t=0 + 0 = 0
"2": scheduled-time = t=0 + 100 = 100
"3": scheduled-time = t=200 + 0 = 300
"4": scheduled-time = t=400 + 0 = 400
But, what Chrome apparently used to do and still does in its other branches is that they only do look at the milliseconds param to do the ordering and ignore the first "that started before this one" condition.
So in there we've got,
"1": milliseconds = 0
"3": milliseconds = 0
"4": milliseconds = 0
"2": milliseconds = 100
Below is a rewrite of this logic:
// We use a MessageChannel to hook on each iteration of the event loop
function postTask(cb) {
const channel = postTask.channel ??= new MessageChannel();
const { port1, port2 } = channel;
port1.addEventListener("message", (evt) => { cb() }, { once: true });
port1.start();
port2.postMessage("");
}
const timers = new Set();
let ended = false; // So we can stop our loop after some time
function timeoutChecker() {
const now = performance.now();
const toCall = Array.from(timers)
.filter(({ startTime, millis }) => startTime + millis <= now)
.sort((a, b) => a.millis - b.millis);
while(toCall.length) {
const timer = toCall.shift();
timers.delete(timer);
timer.callback();
}
if (!ended) {
postTask(timeoutChecker);
}
}
function myTimeout(callback, millis) {
const startTime = performance.now();
timers.add({ startTime, millis, callback });
}
// Begin our loop
postTask(timeoutChecker);
// OP's code
function run() {
myTimeout(() => console.log("1"), 0);
myTimeout(() => console.log("2"), 100);
let start = Date.now();
while (Date.now() - start < 200) {
// do nothing
}
myTimeout(() => {
console.log("3");
}, 0);
start = Date.now();
while (Date.now() - start < 200) {
// do nothing
}
myTimeout(() => {
console.log("4");
}, 0);
}
run();
// all should be done after 1s
setTimeout(() => ended = true, 1000);
As for why you sometimes may see "2" before "4" in Chrome and node.js, it's because they do clamp 0ms timeout to 1ms (thought they're working on removing this in Chrome). So when the event loop gains control at t=400, this log("4") timeout may not have met the timer condition yet.
Finally about Chrome's branch thing, I must admit I'm not sure at all what happens there. Running a bisect (against Canary branch) I couldn't find a single revision where the current stable branch behavior happens, so this must be a branch settings thing.
This question already has answers here:
What is the reason JavaScript setTimeout is so inaccurate?
(5 answers)
Closed 1 year ago.
let count = 60;
function timeLeft(){
count = count - 1;
if(count == 0){
count = 60;
}
}
setInterval(() => timeLeft(), 1000)
setInterval(() => machoAirline.changePrice(), 60000);
setInterval(() => yenoTech.changePrice(), 60000);
This code is the countdown for showing how much time is left until stocks' prices change. But after some minutes, there is a gap between counter and prices update.
console:
price updated!
counter: 42
What's the problem?
Timeout and intervals may take longer to fire when you want due to:
inactive of tabs
throttling of tracking scripts
Late timeouts because browser busy with other tasks.
If you need correct order of machoAirline and yenoTech execution you can combine them in one setInterval:
setInterval(() => {
machoAirline.changePrice();
yenoTech.changePrice();
}, 60000);
setInterval does not keep accurate time, as described in other answers. This means that calculating elapsed time by counting the invocations of setInterval will result in inaccurate timings when compared to wall-time (or indeed, other intervals that you have set).
performance.now() is the most accurate measure of time available in the browser.
If timing is critical, then consider polling performance.now() in the body of a setInterval callback that runs at a short interval...
Something like:
const now = performance.now();
const finishTime = now + 3000; // 3s time
const handle = setInterval(() => {
if (performance.now() >= finishTime) {
console.log("some action");
clearInterval(handle); // kill the timer
}
}, 100); // poll every 100ms (ish)
I'm making a music composer and to play the notes i'm waiting for the time (in ms) to pass before playing the next notes, i've seen that this seems farily inaccurate with sometimes up to 10ms of inaccuracy, is there a way i can make a more accurate timeout or delay function to get down to 0/1 ms of discrepancy?
My code currently is:
function delayMs(ms) {
return new Promise(resolve => {
setTimeout(resolve, ms)
})
}
with the "tick" function:
while (this.state.isPlaying) {
const { song, settings } = this.state
let msPerBPM = Math.floor(60000 / settings.bpm.value)
await delayMs(msPerBPM)
this.handleTick()
}
i'm able to use service workers as i've noticed that i get this issue with delays from re renders in react.
It is easy enough to demonstrate that using setTimeout (and by extension setInterval) you will never get millisecond accuracy.
The below demonstrates that even telling javascript to execute in 1 millisecond it can be anywhere from a few ms to tens of ms later the call is actually made.
function recall(count){
console.log(new Date())
if(++count<10)
setTimeout(recall,1,count);
}
recall(1)
You might have more luck with requestAnimationFrame but again you'll need to calculate how long has elapsed since last step and use that to "synchronise" whatever you want to do:
let start;
function step(timestamp) {
if (start === undefined)
start = timestamp;
const elapsed = timestamp - start;
console.log(elapsed);
if (elapsed < 500) { // Stop the animation after 0.5 seconds
window.requestAnimationFrame(step);
}
}
window.requestAnimationFrame(step);
I'm running a 3 minutes timeout and in that timeout i am running another function at particular durations.But when i'm trying to cancel the timeout its still running and the function inside it is still getting executed.Here's my code
$scope.time = 180000;
var timer = function() {
if ($scope.time > 0) {
$scope.time -= 1000;
var durations = [170000, 150000, 130000, 110000, 90000, 70000, 50000, 30000, 10000];
if (durations.includes($scope.time)) {
dataService.acceptNotify(payload).then(function(response) {
console.log(response);
if (response.data.success === true) {
$mdToast.showSimple(response.data.msg);
$mdDialog.hide();
$timeout.cancel(timeout);
}
})
}
$timeout(timer, 1000);
} else {
$mdDialog.hide();
}
}
var timeout = $timeout(timer, 1000);
You are just not capturing the timer instance into your variable, hence not cancelling it.
Try changing this line in your code:
$timeout(timer, 1000);
to
timeout = $timeout(timer, 1000);
I believe timeout is happening but you are not able to observe it. I see you are calling function timer after every 1 sec with this code
var timeout = $timeout(timer, 1000);
but you are canceling it after getting the response api and in meantime there would have been many instance started which will call that many time. so actually it's cancelling but after few times.
For example, if you get response in 20 sec, then it would be cancelled after calling api 20 times as your code is such.
I can help you with right code if you tell me what you want to do above
Just remove below code which you are using above else block.
$timeout(timer, 1000);
It will work for you.
I'm working on a chat application, which polls the server at a timeout.
The timeout increases if, over time, there hasn't been any recent activity.
The function loadNew() performs an ajax call to the server, which responds with message data.
pollTimeoutTime = 500;
function poll() {
pollTimeout = setTimeout(function(){
loadNew();
if (!new_messages_count) {
//Increasing delay between polls as no messages are incoming to a maximum of 1 minute/60 seconds
if (pollTimeoutTime < 60000) pollTimeoutTime = pollTimeoutTime * 1.25;
}
else {
//Reset delay between poll to default of 0.5 seconds
pollTimeoutTime = 500;
}
poll();
},pollTimeoutTime);
}
The problem I'm having is that the timeout function does not wait for the function loadNew() to complete, which causes the same poll to be sent twice or more if the timeout is lower than the time it takes for the ajax call in the function to complete.
The server thus responds with the same data multiple times, which leads to duplicative display of messages in the chat.
Is there a way to make the timeout only trigger after loadNew() has finished fetching and displaying the data?
EDIT: after using #Brad M's answer, it doesn't duplicate messages anymore. I would still like to have a way to call for a poll after the user submits a message, so the new message is displayed immediately. This would interfere with the timeout set in loadNew(), which would cause messages to be duplicated again. Could you think of a way to get that working?
Without seeing your loadNew function, an easy fix might be to change that function to return your ajax call (return $.ajax({...});) and change the code you posted to this:
pollTimeoutTime = 500;
function poll() {
pollTimeout = setTimeout(function () {
loadNew().done(function (result) {
if (!new_messages_count) {
//Increasing delay between polls as no messages are incoming to a maximum of 1 minute/60 seconds
if (pollTimeoutTime < 60000) pollTimeoutTime = pollTimeoutTime * 1.25;
} else {
//Reset delay between poll to default of 0.5 seconds
pollTimeoutTime = 500;
}
poll();
});
}, pollTimeoutTime);
}
Use ajax callback functions such as success or complete to trigger a new poll.