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!
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
Related
I am building a progressive web app using React, the concept of which revolves around keeping a timer running.
For context, the app is for home-brewers to keep track of when hops and other additions need to be added to their boil during their brew. Additions are added with a certain amount of time remaining in the boil, i.e. 1 oz Citra hops at 20 minutes remaining.
I'm using JavaScript's setInterval to "tick" the timer, which is an elapsedSeconds state property that drives the rest of the application.
The problem I'm running into is when the timer stops ticking. If I let the app run, the screen will eventually lock, or I'll switch apps, etc. The service worker will continue running, and the timer will continue to tick, for a short time (about 10 minutes from what I can tell in testing?)
My thought is that I will store an epoch time in state, that represents the time when the timer started. That way, when a user "returns" to the PWA, I can compare the current epoch time against the stored startingEpochTime to get the elapsedSeconds back. But I don't want to do this comparison at every "tick" if I don't have to. Ideally, this comparison would only run when the user is returning to the application from some other context, after the service worker has already stopped processing.
What I'm looking for is the correct way to do this. Would window.onload work in this instance? If I switch apps to another app for 20 minutes then switch back to my timer app, is that method run again? Looking for the best practice for this sort of scenario, or any idea that might help me out.
As of 2022 there is no way of scheduling tasks or keeping a timer running when a PWA is moved into the background.
To everyone who wants this functionality, please star and comment on the Google issue requesting it to motivate them to act: https://bugs.chromium.org/p/chromium/issues/detail?id=889077
Here's a couple of pointers that can help:
The general solution to what you describe is the Wake Lock API, which is the process of being design and specified, but is not available anywhere by default (yet).
In terms of what's currently implemented, there are pretty reliable ways of at least detecting when your web app goes into the background and goes back into the foreground using the Page Lifecycle API events. Once you're reliably detecting when you've come back to the foreground, a technique like what's mentioned in the comments about comparing the start time to the current time sounds about right.
I need to perform many "setTimeouts" 60 seconds. Basically, I'm creating a database record, and 60 seconds from now, I need to check whether the database record was changed.
I don't want to implement a "job queue" since it's such a simple thing, and I definitely need to check it around the 60 second mark.
Is it reliable, or will it cause issues?
When you use setTimeout or setInterval the only guarantee that you get is that the code will not be executed before the programmed time.
It can however start somewhat later because other code that is being executed when the clock ticks (in other words other code will not be interrupted in the middle of the handling of an event to process a timeout or interval event).
If you don't have long blocking processing in your code it means that timed events will be reasonably accurate. If you are instead using long blocking calls then probably node is not the correct tool (it's designed around the idea of avoiding blocking "synch" calls).
you should try WorkerTimer.js it is more good for handling background processes and more accurate than the traditional setInterval or Timeout.
it is available as a node.js npm package.
https://www.npmjs.com/package/worker-timer
I'm designing an app to run on very low spec machine..and i needed it to be efficient as possible..
I needed to issue around 10 intervals at every second that simply makes an ajax call.. and then does a few add/remove classes and (think of it as SERVER Status monitor)
I know in FLASH (oh good old flash days) having a lot of intervals can cause processor spikes .. so i'm very conservative with issuing setIntervals in AS 2.0 before.
I was wondering if this is the same case with JS? or is it alright for JS to have a bunch of intervals (that does lightweight tasks) running? I noticed a lot of sites do this , even facebook has tons of intervals running, loading scripts, etc..
And oh, for one interval, I wanted to run it at 50ms (it loads as status.php link) ... this ok?
I could probably optimize my interval calls, no problem but i'm just wondering how "heavy" or "lightweight" background intervals are in JS..
Thanks all
10 intervals at every second meaning a call every 100ms should not be an issue in my opinion, but if you ask me I would fire a call every 250ms.There is not much difference between the two that the user will notice.
Also make sure that there is a mechanism to handle long running response from server in case there is a delay and stop the interval firing if there is drag.
As a matter of personal feeling, I tend to prefer setTimeout over setInterval -- to the point I don't use setInterval at all.
The issue that you might run into is if one process takes longer than it should -- let me give you an imaginary situation:
window.setInterval(takes100msToRun, 50);
window.setInterval(takes50msToRun, 50);
window.setInterval(takes20msToRun, 50);
The problem is that the first interval will take longer than it should, so the second two interval requests are now behind and the browser will try to catch up by running them as quickly as then can. The second interval takes 50ms, -- so its still running behind when the third interval hits.
This creates an ugly situation that can lead to a lot of drag.
On the other hand, if you setTimeout, then you aren't say "Run this every 50 ms", but rather "Run another one of these 50ms from we finish." (Assuming, of course, that the functions set up another setTimeout to re-execute.)
It is absolute rubbish for things that need good clock timing, but its superior for everything else.
setTimeout and setInterval will affect performance, but little.
Since there are lots of functions triggered/listening/running in the browser.
Even a tiny operation like move your mouse to vote up for this answer, there are thousands of events got triggered, and tens of functions start running.
Don't use setInterval. As a matter of fact, the library underscore doesn't use it either.
See how they implement the _.throttle without setInterval.
http://learningcn.com/underscore/docs/underscore.html#section-66
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);
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)
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
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.
The answer to your question depends on:
The device you execute this on
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/
I know both ie and firefox have limits for javascript execution (Source 1, Source 2). Based on number of statements executed, I heard it was 5 million somewhere in IE and based on number of seconds in firefox: it's 10 seconds by default for my version.
The thing I don't get is what cases will go over these limits:
I'm sure a giant loop will go over the limit for execution time
But will an event hander go over the limit, if itself it's execution time is under the limit but if it occurs multiple times?
Example:
Lets say I have a timer on my page, that executes some javascript every 20 seconds. The execution time for the timer handler is 1 second. Does firefox and ie treat each call of the timer function seperatly, so it never goes over the limit, or is it that firefox/ie adds up the time of each call so after the handler finishes, so after 200 seconds on my site (with the timer called 10 times) an error occurs even though the timer handler itself is only 1 second long?
The following article by Nicholas C. Zakas discusses how and when different browsers interrupt long running JavaScript code:
What determines that a script is long-running?
Breaking long processing code into small chunks and launching them with timers is in fact one way to get around this problem. The following Stack Overflow post suggests a method to tackle this:
Show javascript execution progress
On the other hand, web workers would be more suited for long running processing, since their execution happens in a separate process, and therefore does not block the UI thread:
Mozilla Dev Center: Using web workers
John Resig: Computing with JavaScript Web Workers
Nicholas C. Zakas: Experimenting with web workers
However web workers are not supported in Internet Explorer yet, and they would not have access to the DOM.
The event handler is considered a new execution context - the time limit is reset.
If you need to do even more computation, take a look at WebWorkers.
I too stuck in this kind of JS error. I also get the solution, unfortunately only for IE, which tells to edit the registry (regedit command) and update the number of JS commands to allow. Read more here http://support.microsoft.com/?kbid=175500.
But this doesn't seems to be a good solution to me bcoz if you are developing a web application you can not ask every user to use only IE and update his system registry.
As a workaround: If your data to process at client end is really large then you can put some manual delays between fix set of events processing. For ex. If there are 100 events of any task you want to process then you can break them in to 10 sets of 100 and process each of them in say 100ms. To know how to do that follow below link:
http://www.nczonline.net/blog/2009/01/13/speed-up-your-javascript-part-1/