4

I'm working on a site that has some interesting Javascript in it and I'm worried it may cause performance issues on slower machines.

The script uses setInterval to run a handler EVERY SECOND. The handler does the following:

  1. Read a single cookie value (using a jquery cookie plugin)
  2. Update its value and expiration date
  3. Write it back to the cookie jar

The cookie has an expiration date so it should theoretically be written to disk every time, not held in memory.

So far it works great on my PC, but I have a fast machine with a solid state drive. Do you think this design will cause issues on a slower box or a busy hard disk? Possible cause a minor stammering effect that happens every 1 second? Just looking for some reassurance that this design isn't absolutely insane. Thanks.

John Wu
  • 44,075
  • 6
  • 37
  • 69
  • 3
    Well, you're not asking the right question. You should ask yourself if writing a cookie every second is really necessary. – Simon Boudrias Sep 20 '13 at 15:06
  • 4
    Thank you Simon, we actually already did ask that question and the answer is more or less yes. Please don't assume we didn't think it through. Thanks for your reply. – John Wu Sep 23 '13 at 10:47
  • 1
    Every second? That should hardly make any performance issue. – Bergi Oct 03 '13 at 02:00
  • 1
    Out of curiosity, though, why are you doing that? – Ja͢ck Oct 03 '13 at 02:02
  • It's part of a much larger authentication mechanism (much of which is out of our direct control) that handles some of the more tricky aspects of user behavior-- multiple tabs, navigating away without logging out, etc. The application is in the financial industry and we are putting in some serious defense-in-depth measures to keep the user from leaving himself in an unsecure state. The status of the cookie tells us the exact moment when the user last had the page up and visible in any browser window. – John Wu Oct 03 '13 at 16:45

1 Answers1

5

In the browser, JavaScript execution is single-threaded. This means that, while JS code is running setInterval functions will not run. Equally, while setInterval functions are running, other JS code (such as event handlers) will not run.

So, it's certainly important to ensure that code that is run at short intervals performs well.

In this case, you have code that runs once a second, so it's important that it takes << 1s to complete, or you run the risk of never leaving enough time for other actions to occur.

There is some performance data on accessing cookies with jQuery (and without) available here.

What it shows is that reading and writing is sufficiently fast that you should be able to do it without taking too much up of your 1s update interval.

Another approach might be to try the following

var timeoutId;
var timeoutSetter = function(timeout) {
    timeoutId = setTimeout(function() {
        cookieUpdate();
        timeoutSetter(timeout);
    }, timeout);
};

timeoutSetter(1000);

This means that the cookies wont be update until 1s after the last update, regardless of how long the update itself takes... probably overkill and it leads to some fairly gnarly code, but its an option.

Update

Following Bergi's comment below, I thought an example would be instructive.

Go to http://jsfiddle.net/meYc5/2/ and open the console. You'll see a log of Foo clicked each time you click the yellow box. If you click repeatedly, you'll see it flips from yellow to red and back. There is a perceptible delay. That's because it's currently configured to block the setInteval thread for 500ms once every second. This means that events are handle at a duty cycle of 50%.

In addition, you'll notice the cursor in the textarea is less responsive.

This (500ms) would be a pretty extreme amount of time for update cookies, but it illustrates the principle. If you are doing something with setInterval, you should make sure that the 

execution time of the handler << interval period

so that you maintain a high enough duty cycle to process events.

Dancrumb
  • 23,732
  • 7
  • 60
  • 127
  • Well, 1s is not a *short interval* - and any code that runs for about a second should be fixed, not put in (any) interval :-) – Bergi Oct 03 '13 at 02:17
  • It's a short interval for a user and if the code added any kind of disruption to UI behaviour, then at an interval of 1s it would be enough to drive them off the site. Also, the code wouldn't have to run for 1s for the impact to be felt. – Dancrumb Oct 03 '13 at 02:20
  • Thank you for your answers. – John Wu Oct 08 '13 at 17:20