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 uping 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!

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 uping 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!

• javascript
• performance
• settimeout
• reminders

• 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 Commented Dec 18, 2013 at 23:03
• it's a very plex 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. Commented Dec 18, 2013 at 23:07
• 1 Ok, thought maybe you meant set a timeout for multiple events at once, which would be unnecessary. Sounds reasonable. – crad Commented Dec 18, 2013 at 23:09

2 Answers 2

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

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