Hacker News Reader

Comment by CGamesPlay | Hacker News Reader

So you get to use 1% CPU, effectively. The timer test seems strange, why was your "simple setInterval" using so much more than 1% CPU?

View on HN

No, you don't get to use 1% CPU. That would still work. The problem is that you get to use 100% of CPU but only 1% of the time.

A timer task is only allowed to run when the budget is non-negative.

After a timer has executed, its run time is subtracted from the budget.

The budget regenerates with time (at rate of 0.01 seconds per second).

I think that would imply that if in any given second, your timer code runs for <= 10 milliseconds, then you will never run out of budget. Right?

So for things like sending out heartbeat packets to keep connections alive, I'm assuming that doesn't count, because it happens asynchronously (waiting for the response, I mean)? If that's the case, and your 10 milliseconds only applies to running JavaScript on the CPU, then 10 milliseconds seems reasonable to me. It's a background tab, after all, it's disrespectful of your users to abuse their CPU more than that.

Explain how that is different?

It's different because it can't just slow down a running task.

Say you use up 150ms of CPU time. Chrome isn't going to let another timer fire for 15s. Then, you're late on a whole bunch of work that needs to get done, so the next timer takes 500ms. Chrome then throttles the next timer by 50s. And so on and so forth...

But if your script had 1% of CPU, that 150ms workload would take 15s to complete. Then the next workload would be late in the same way and take 50s to complete.

How is this different?

It depends on what you're doing. If you split up tasks and interleaves them (such as: process a few items, stop, set another timer, process a few more), actual CPU% throttling would be better. It would be easier to have certain timers take priority, such as heartbeat responses or notifications.

Reply on news.ycombinator.com