Is setInterval CPU intensive?

I read somewhere that setInterval is CPU intensive. I created a script that uses setInterval and monitored the CPU usage but didn't notice a change. I want to know if there is something I missed.

What the code does is check for changes to the hash in the URL (content after #) every 100 milliseconds and if it has changed, load a page using AJAX. If it has not changed, nothing happens. Would there be any CPU issues with that.

46221 次浏览
小开

No, setInterval is not CPU intensive in and of itself. If you have a lot of intervals running on very short cycles (or a very complex operation running on a moderately long interval), then that can easily become CPU intensive, depending upon exactly what your intervals are doing and how frequently they are doing it.

I wouldn't expect to see any issues with checking the URL every 100 milliseconds on an interval, though personally I would increase the interval to 250 milliseconds, just because I don't expect that the difference between the two would be noticeable to a typical user and because I generally try to use the longest timeout intervals that I think I can get away with, particularly for things that are expected to result in a no-op most of the time.

小开

I would rather say it's quite the opposite. Using setTimeout and setInterval correctly, can drastical reduce the browsers CPU usage. For instance, using setTimeout instead of using a for or while loop will not only reduce the intensity of CPU usage, but will also guarantee that the browser has a chance to update the UI queue more often. So long running processes will not freeze and lockup the user experience.

But in general, using setInterval really like a lot on your site may slow down things. 20 simultaneously running intervals with more or less heavy work will affect the show. And then again.. you really can mess up any part I guess that is not a problem of setInterval.

..and by the way, you don't need to check the hash like that. There are events for that:

onhashchange

will fire when there was a change in the hash.

window.addEventListener('hashchange', function(e) {
console.log('hash changed, yay!');
}, false);
小开

There's a bit of marketing going there under the "CPU intensive" term. What it really means is "more CPU intensive than some alternatives". It's not "CPU intensive" as in "uses a whole lot of CPU power like a game or a compression algorithm would do".

Explanation :

Once the browser has yielded control it relies on an interrupt from the underlying operating system and hardware to receive control and issue the JavaScript callback. Having longer durations between these interrupts allows hardware to enter low power states which significantly decreases power consumption. By default the Microsoft Windows operating system and Intel based processors use 15.6ms resolutions for these interrupts (64 interrupts per second). This allows Intel based processors to enter their lowest power state. For this reason web developers have traditionally only been able to achieve 64 callbacks per second when using setTimeout(0) when using HTML4 browsers including earlier editions of Internet Explorer and Mozilla Firefox.

Over the last two years browsers have attempted to increase the number of callbacks per second that JavaScript developers can receive through the setTimeout and setInterval API’s by changing the power conscious Windows system settings and preventing hardware from entering low power states. The HTML5 specification has gone to the extreme of recommending 250 callbacks per second. This high frequency can result in a 40% increase in power consumption, impacting battery life, operating expenses, and the environment. In addition, this approach does not address the core performance problem of improving CPU efficiency and scheduling.

From http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html

小开

In your case there will not be any issue. But if your doing some huge animations in canvas or working with webgl , then there will be some CPU issues, so for that you can use requestAnimationFrame.

Refer this link About requestAnimationFrame

小开
最佳答案

I don't think setInterval is inherently going to cause you significant performance problems. I suspect the reputation may come from an earlier era, when CPUs were less powerful.

There are ways that you can improve the performance, however, and it's probably wise to do them:

  1. Pass a function to setInterval, rather than a string.
  2. Have as few intervals set as possible.
  3. Make the interval durations as long as possible.
  4. Have the code running each time as short and simple as possible.

Don't optimise prematurely -- don't make life difficult for yourself when there isn't a problem.

One thing, however, that you can do in your particular case is to use the onhashchange event, rather than timeouts, in browsers that support it.

小开

Function time > interval time is bad, you can't know when cpu hiccups or is slow one and it stacks on top of ongoing functions until pc freezes. Use settimeout or even better, process.nextick using a callback inside a settimeout.


提交答案