On 10/29/2012 03:16 PM, verlag.preis...@t-online.de wrote: >> 3. Bizarre observations when using high-resolution (or even ms-res) >> clocks and timers... seems like you can't get more than about 0.1-sec >> resolution or so reliably -- or at least plausibly -- on a win32 box. > > Hmm, I think this applies for outdated versions of Windows like WinXP, which > don't support HPET timers. > I remember when I wrote a java snippet at my WinXP machine at work like this: > > > long startTime = System.nanoTime(); > // do something which doesn't take much time... > long duration = System.nanoTime() - startTime; > > and then being surprised that "duration" contained a negative value...
As much as I hate to give windows the benefit of the doubt, there is a plausible explanation where windows wasn't technically doing anything wrong: if you were setting your clock via NTP, it's possible that there was a clock-correction in process. POSIX dealt with this (relatively recently in unix terms) by introducing a couple functions; one that lets to see what the system thinks its clock resolution is, and also a way to access a monotonic clock (guaranteed to be unaffected by system-clock corrections). There is another platform-specific issue that bit me once: Windows+NTFS is really horrible at dealing with directories with large numbers of files. I once had a web app that scanned directories containing a few thousand files looking for the most recent file. On linux (w/ ext3), there was no noticeable time difference between a directory with 2 or 2000 entries. On windows, small directories were as fast as linux, but once the number of files in the directory got large, the operation would take on the order of minutes. Most people avoid that issue by using a DB to store their data (and let the DB implement platform-specific optimizations) instead of trying to use flat files, but we had a special requirement (integration w/ third-party tool). Matt --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
