Make updateInterval user-settable

[briansayles]

It would be beneficial to be able to set the timer to update more often than every second. Currently var updateInterval = 1000 and is not settable by the user. It would be nice if it would be able to be set via either TimeSync.updateInterval = xxx; or TimeSync.setUpdateInterval(xxx);

I am currently working on a countdown timer, and while I don't need the timer resolution to be any more precise than 1 second, it would be beneficial for the updateInterval to be less than 1 second. The reason for this is that individual machines will 'tick' at different fractions of a second based on when their timer was started (at page render in my case). So if one device renders at xx:xx:xx.250 and another renders at xx:xx:xx.750, their ticks will be 1/2 second off from each other. So when you watch a countdown on both machines, they're slightly out of sync, just because of when they tick. If I set the updateInterval for something in the area of 250 ms, the noticeable difference between the different devices essentially disappears. Going below that could make it literally disappear, but is not necessary in my case.

[mizzao]

I've thought of this before too but didn't want to implement it until someone actually needed it. The general case is to make an update timer for any interval requested, rather than just limiting it to the global value.

For best efficiency, the solution is probably to make a reactive computation for each interval requested, so that all timers with 250ms intervals are recomputed at the same time rather than all independently. Otherwise there will be a lot of setIntervals running in the background. Should be pretty easy to do.

I'm currently on vacation and would be happy to take a look when I get back.

[briansayles]

Awesome. I'm in no big hurry for this. Thanks. Really like this library and will support it going forward.

On Aug 22, 2014, at 1:40 AM, Andrew Mao notifications@github.com wrote:

I've thought of this before too but didn't want to implement it until someone actually needed it.

For best efficiency, the solution is probably to make a reactive computation for each interval requested, so that all timers with 250ms intervals are recomputed at the same time rather than all independently. Should be pretty easy to do.

I'm currently on vacation and would be happy to take a look when I get back.

— Reply to this email directly or view it on GitHub.

[hanssnabilie]

hi Mizzao,

I was wondering if this was still on the roadmap? I would like to set this value to 60 seconds since my visual scale is not smaller than that. It's now doing quite a bit of calculations 59 times per minute more than necessary :)

[mizzao]

@hanssnabilie It is to be done, but competing with a lot of other things for attention :)

For now, are you sure you're not doing premature optimization? How much CPU is your app using in the steady state, and could you reduce the amount of calculations done in the reactive computation that is dependent on time?

[hanssnabilie]

The nature of the app is so that it stays in the foreground for long periods. It needs to be light because of that, the time part is the only neccessary element :) I can of course work around it but it will be just that, working around a limitation. A lib should be facilitating, not demanding workarounds no? :)

Anyway I did work around it for now so no immediate need for me. I do think its an important addition though.

[mizzao]

Yes, that's true - but the library is also open-source and comes from one's spare time. Feel free to submit a PR if you are in the mood before I am.

[hanssnabilie]

Yes fair enough. I wasn't trying to push you, sorry if I gave you the impression.

I realised that the problem was with me, I was simply using the wrong tool for the job. Timesync's concept is to get an as accurate time as possible. If you need, as I do, anything thats doesn't need to be synced every second then a simple server call for the time works perfectly fine.

[mizzao]

No, you're right though. This is an important feature that just hasn't been implemented yet.

Other than what you said, the goal of TimeSync is to be able to use time reactively on the client while minimizing the load on the server. Making server calls every minute to get the time misses both of those goals :) Perhaps you want to try a setTimeout where the time value is retrieved non-reactively, for now.

[mizzao]

You can now use TimeSync.serverTime(null, XXX) where XXX is an integer number of milliseconds specifying the rate that you'd like the variable to update at, default 1000.

[briansayles]

Excellent. Thank you. While I don't really need this functionality any more because I refactored my app a bit (per your recommendation which was good), I think it's a good feature for your package.

On Feb 10, 2015, at 11:06 PM, Andrew Mao notifications@github.com wrote:

You can now use TimeSync.serverTime(null, XXX) where XXX is an integer number of milliseconds specifying the rate that you'd like the variable to update at, default 1000.

— Reply to this email directly or view it on GitHub.