Home  >  Article  >  Web Front-end  >  Let’s talk about the reasons why you should try not to use setInterval

Let’s talk about the reasons why you should try not to use setInterval

青灯夜游
青灯夜游forward
2021-01-08 18:37:554833browse

Let’s talk about the reasons why you should try not to use setInterval

Why try not to use setInterval? The following article will briefly discuss the reasons why you should try not to use setInterval. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to everyone.

When developing an online chat tool, there is often a need to perform an operation repeatedly after a certain number of milliseconds. "No problem," everyone said, "just use setInterval." I think this idea is terrible.

One of the reasons: setInterval ignores code errors

setInterval has an annoying habit of reporting errors to the code it calls. indifferent. In other words, if the code executed by setInterval goes wrong for some reason, it will continue to call that code regardless of it. Look at the code

function a() {
    try{
        a.error.here;
    } catch(e){
        $(&#39;body&#39;).append(&#39;<div>&#39; + e.toString() + &#39;</div>&#39;);
        throw e;
    }
}
function b() {
    try{
        b.error.here;
    } catch(e)
    {
        $(&#39;body&#39;).append(&#39;<div>&#39; + e.toString() + &#39;</div>&#39;);
        throw e;
    }
    setTimeout(b, 2000);
}
setInterval(a, 2000);
setTimeout(b, 2000);

The second reason: setInterval ignores network delay

Assume that you poll the server through Ajax every once in a while, see See if there is new data (note: if you do this, you are probably doing it wrong; it is recommended to use "compensatory polling" (backoff polling) [1]). And due to some reasons (server overload, temporary network outage, sudden increase in traffic, limited user bandwidth, etc.), your request will take much longer than you think. But setInterval doesn't care. It will still fire requests on a regular basis and eventually your client network queue will be filled with Ajax calls. Look at the code

var n = 0,
    t = 0,
    u = 0,
    i, s = &#39;Stopping after 25 requests, to avoid killing jsfiddle’s server&#39;;
function a() {
    $.post(&#39;/ajax_html_echo/&#39;, function () {
        --n;
    });
    ++n;
    ++t;
    $(&#39;#reqs&#39;).html(n + &#39; a() requests in progress!&#39;);
    if (t > 25) {
        clearInterval(i);
        $(&#39;#reqs&#39;).html(s);
    }
}
function b() {
    ++u;
    $.post(&#39;/ajax_html_echo/&#39;, function () {
        $(&#39;#req2&#39;).html(&#39;b(): &#39; + new Date().toString());
        if (u <= 25) {
            setTimeout(b, 500);
        } else {
            $(&#39;#req2&#39;).html(s);
        }
    });
}
i = setInterval(a, 500);
setTimeout(b, 500);

The third reason: setInterval is not guaranteed to be executed

Unlike setTimeout, you cannot guarantee that the code will be accurate when the time interval is reached Can be executed. If the function you call takes a long time to complete, some calls will be simply ignored. Look at the code

function slow() {
    $.ajax({
        url: &#39;/echo/html/&#39;,
        async: false,
        data: {
            delay: 1
        },
        complete: function () {
        }
    });
    $(&#39;#reqs&#39;).text(~~((new Date() - start) / 100) + &#39; expected, &#39; + iters + &#39; actual&#39;);
    if (iters++ > 4) {
        $(&#39;#reqs&#39;).append(&#39;<br>Stopping after 5 iterations&#39;);
        clearInterval(iv);
    }
};
var iv = setInterval(slow, 100), start = +new Date(), iters = 0;

The solution is simple: use setTimeout

Instead of using setInterval, it is better to call the function itself through setTimeout at the appropriate moment . In the previous two examples, function a using setInterval errors, while function b using setTimeout performs well.

What if the intervals must be equal?

If you really want to ensure that the event is triggered "evenly", you can subtract the time spent on the last call from the desired delay, and then dynamically assign the resulting difference to setTimeout as a delay. . However, it should be noted that JavaScript timers are not very accurate [2]. So you can't get absolutely "average" latency, even with setInterval, for many reasons (garbage collection, JavaScript being single-threaded, etc.). In addition, current browsers will also fix the minimum timeout period between 4ms and 15ms. So don't expect no errors at all.

For more programming-related knowledge, please visit: Programming Teaching! !

The above is the detailed content of Let’s talk about the reasons why you should try not to use setInterval. For more information, please follow other related articles on the PHP Chinese website!

Statement:
This article is reproduced at:cnblogs.com. If there is any infringement, please contact admin@php.cn delete