85

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.

Ryuku
  • 853
  • 1
  • 6
  • 5
  • 3
    Really depends on the function being called and the amount of time you specify. Obviously calling a function every 100 miliseconds that is 1000 lines long will be cpu intensive. – Shaz Jul 11 '11 at 12:38
  • 2
    On Chrome, the interval function is only called once per second if the tab is inactive, by the way. So if your website/application is not active, it is certainly CPU friendly. – pimvdb Jul 11 '11 at 12:41
  • Is it necessary to poll for the changes? Can you not just add click handlers for all your anchors? – davin Jul 11 '11 at 12:44
  • Thanks for the responses everyone, they were very helpful. – Ryuku Jul 11 '11 at 12:46
  • @davin: Yeah, I do that, but the problem is if the user clicks the back button or manually changes the URL. – Ryuku Jul 11 '11 at 12:46
  • @Ryuku: Just on a side note, there is the `onhashchange` event. – pimvdb Jul 11 '11 at 12:49
  • This might not be relevant to your actual question, but you can use built-in window.onHashChange() instead of that interval. – Ben Bozorg Mar 16 '17 at 02:42

6 Answers6

87

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.

lonesomeday
  • 233,373
  • 50
  • 316
  • 318
  • 2
    Thanks for the advice. All the responses to this thread have been very helpful, and I thank you all for it. I chose this answer because onhashchange was very useful. – Ryuku Jul 11 '11 at 12:55
  • 1
    Wow a very thorough and concise answer! Thanks for the tips! – Yes Barry Sep 20 '12 at 04:01
  • 2
    I would vote this up for the "Don't optimise prematurely" alone. Nice and concise, very helpful. – ghukill Oct 23 '15 at 13:41
19

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);
Arun Bertil
  • 4,598
  • 4
  • 33
  • 59
jAndy
  • 231,737
  • 57
  • 305
  • 359
14

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.

aroth
  • 54,026
  • 20
  • 135
  • 176
4

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

user703016
  • 37,307
  • 8
  • 87
  • 112
4

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

Sarath
  • 9,030
  • 11
  • 51
  • 84
2

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.

huseyin tugrul buyukisik
  • 11,469
  • 4
  • 45
  • 97