On 20/03/2015 07:36, Julian Reschke wrote: > On 2015-03-20 01:48, Alexander Klimetschek wrote: >> AFAIK, this is expected, on Windows (or some Windows versions), >> System.currentTimeMillis() only has a resolution of 15ms >> >> http://stackoverflow.com/questions/7859019/system-currenttimemillis-is-not-accurate-on-windows-xp >> >> >> Cheers, >> Alex > > That's not really true, see > <http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/201403.mbox/%[email protected]%3E> > - you need to distinguish the clock (which can be as "good" as 1ms, > see above mail), from timers. Can we do a quick test? Let's put the scheduler to 15ms or 20ms and see if it still fails for windows. AFAIR the purpose of Clock.FAST was to have a non-accurate but fast clock.
> Anyway, it seems to me that Clock.Fast can't be made to work reliably, > and also that we really don't understand the reason why we don't > simply use Clock.SIMPLE. We currently use Clock.Fast in RepositoryImpl > and StopWatchLogger; we should have a look at these uses, and decide > whether we can switch to Clock.SIMPLE. I can speak of the StopwatchLogger (SWL) as I coded it. It was meant for having a common interface for tracking executions timing in logs. It uses the Clock.FAST as it was meant to be as less impacting performance as possible and it was not meant to replace a profiler; so an accuracy of 10ms was ok. You can find a usage example here on my GH fork (0). For the SWL class I think that an accuracy of 20ms should be ok. (see above). (0) https://github.com/davidegiannella/jackrabbit-oak/blob/OAK-2472/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/async/AsyncEditorProcessor.java#L140 -- Davide
