4

I am creating a web app that allows users to manage a calendar (CRUD events, tasks, reminders etc...)

And I am trying to implement a feature where they will receive a popup reminder x-minutes before the event/task. From my understanding there is really only one way to do this with javascript:

On login, check for any upcoming events in the database (say in the next 12 hours) and create a setTimeout for the next event, when that setTimeout executes, check again for next event and so on...

My question is, will having multiple setTimeouts (10+) running in the background during user interaction slow down the performance of my app?

Is there a better way to handle popup notifications on the client side? Push Notifications? Any suggestions would be greatly appreciated!

A.O.
  • 3,733
  • 6
  • 30
  • 49
  • Why would you have 10+ running in the background? As you said, set a timeout for the next event. When that fires, check for the one next event and set a new timer. – crad Dec 18 '13 at 23:03
  • it's a very complex app, I use timed notifcations for a lot of things. the event reminders are by far the most important tho....and i really dont see myself having more than 10 i just used that as an upper limit – A.O. Dec 18 '13 at 23:07
  • 1
    Ok, thought maybe you meant set a timeout for multiple events at once, which would be unnecessary. Sounds reasonable. – crad Dec 18 '13 at 23:09

2 Answers2

4

My question is, will having multiple setTimeouts (10+) running in the background during user interaction slow down the performance of my app?

In those numbers, no. (Depending on how + the + in 10+ is. I mean, I expect a million probably would be an issue.)

The other approach would be to have a single timer that you use (say, per minute) to check for notifications that should occur as of that minute. E.g.:

function notifyForThisMinute() {
    // Notify user of things we should notify them of as of this minute
    // ...

    // Schedule next check for beginning of next minute; always wait
    // until we're a second into the minute to make the checks easier
    setTimeout(notifyForThisMinute, (61 - new Date().getSeconds()) * 1000);
}
notifyForThisMinute(); // First call starts process
T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • Yeah i also thought of that approach, but wouldnt that make a lot of unnecessary calls to the server if there were no events for that day?....and I really cant see a situation where I would have more than 10, that's prolly my upper limit – A.O. Dec 18 '13 at 23:06
  • @A.O.: I didn't say it was a server call. :-) You can load the information for the next X minutes and have it locally. – T.J. Crowder Dec 18 '13 at 23:06
  • good point....performance-wise it would be the same tho wouldnt it? one long running setTimeout versus a bunch of consecutive shorter ones? – A.O. Dec 18 '13 at 23:09
  • @A.O.: I suppose it depends on how many notifications will occur on the same minute, the implementation of `setTimeout` on the browser in question, the implementation of your checks for things you need to notify... At the end of the day, I really don't think it'll matter, but I would lean toward a single timer that checks for everything due that minute, if only for the UI aspect (a single list rather than several distinct things). I mean, even if you had a list 1,000 long, checking that once/minute is not going to cause any kind of performance issue. – T.J. Crowder Dec 18 '13 at 23:11
  • Thanks for the advice/assurance! +1 – A.O. Dec 18 '13 at 23:12
4

This depends on the browser (or more specifically, it's javascript engine) and apparently even OS.

Neil Thomas (while working on GMAIL mobile) and John Resig have analyzed timers.

One of the more noticeable things to look out for is how often the timer runs per given time-interval (say every 200ms or once every 10 minutes..).

Thomas:

With low-frequency timers - timers with a delay of one second or more - we could create many timers without significantly degrading performance on either [an Android G1 or iPhone 3G]. Even with 100 timers scheduled, our app was not noticeably less responsive. With high-frequency timers, however, the story was exactly the opposite. A few timers firing every 100-200 ms was sufficient to make our UI feel sluggish.

Thomas:

Keep in mind that this code is going to execute many times every second. Looping over an array of registered callbacks might be slightly "cleaner" code, but it's critical that this function execute as quickly as possible. Hardcoding the function calls also makes it really easy to keep track of all the work that is being done within the timer.

Resig:

Once you start moving into the range of 64-128 simultaneous timers, you’re pretty much out of luck in most browsers.

One might also have a look at Chronos

GitaarLAB
  • 14,536
  • 11
  • 60
  • 80
  • 1
    I just wanted to add that both articles that are quoted here are pretty old (John's is 7 years old for example) and timers have improved in all browsers since, so the information in this answer is not quite correct. – YemSalat Sep 24 '14 at 07:37