16

I wonder if this code is going to put load on the client since the timeout is so long?

        //and update this again in a bit
        setTimeout(function() {
            updateWeather(lat,lng);
        }, 60000);
Matt Welander
  • 8,234
  • 24
  • 88
  • 138

4 Answers4

12

Not that code alone. The system idles for that one minute. As long as updateWeather doesn't have severe performance issues and the interval is short, setTimeout won't be a product (and I believe you mean setInterval, not setTimeout for recurring checks)

bobbybee
  • 1,758
  • 1
  • 16
  • 27
  • Picked your answer since you mention the setInterval - I guess I should be using setInterval in this case, since this sample code is actually inside the updateWeather function itself, at the end of the function. Is this a bad idéa, is there a performance improvement in using setInterval over setTimeout or are they just the same, is setInterval just a handy way of not having to do this self-call that I do? – Matt Welander Oct 25 '13 at 18:15
  • I haven't benchmarked it myself, but in terms of elegance, setInterval is nicer. I'll run a benchmark now. – bobbybee Oct 25 '13 at 23:04
6

The 60 second timer is implemented by magic in the OS: it basically adds no CPU load during the 60 seconds it is waiting.

I guess updateWeather() is polling an external resource, so the answer to your question is a simple "no, it is fine". (As the weather does not change that often, I'd make it 5 minutes instead, see comment below on battery life.) (Even better: see if the weather data provider gives you a field telling you when the next update will be, and use a setTimeout based on that.)

In other situations, for instance if you have been collecting some kind of data for those 60 seconds, and then go and process it in one go, this could cause a peak of heavy load. Which might be noticed by the user (e.g. all animations go jerky once every 60 seconds). In that case it is better to use a 5 second timer, and process 5 seconds worth of data at a time.

Conversely, if you are using the network on a mobile device, you have to consider battery life: wake-up-and-find-a-connection can dominate. So extending a polling time from 60 seconds to 120 seconds can literally double battery life. Ilya Grigorik has a very good chapter on this in his book, High Performance Browser Networking, http://shop.oreilly.com/product/0636920028048.do ...here it is: http://chimera.labs.oreilly.com/books/1230000000545/ch08.html#ELIMINATE_POLLING

Darren Cook
  • 27,837
  • 13
  • 117
  • 217
4

One thing to keep in mind, in addition to the other answers, is the affect that the closure of in-scope variables might have on memory performance. If you've got a gajillion objects being referenced by variables in the scope(s) above your setTimeout callback, those objects may live as long as the callback is queued. That is not something we can tell from the code you posted and so no answer can be definitively given to your question. Also, if your setTimeout is being called multiple times, it will create a closure for each one, effectively duplicating the environment and taking up your heap space.

papiro
  • 2,158
  • 1
  • 20
  • 29
3

The answer to your question depends on:

  1. The device you execute this on
  2. The environment - how many times do you execute this

A standalone setTimeout would not hurt the browser; however, if you are doing the same thing repeatedly, it would make a difference.

Have a look at the following website for more insights...

http://ejohn.org/blog/analyzing-timer-performance/

Gautam Bhutani
  • 395
  • 2
  • 12