[fpc-devel] Problem with Now() and time changed by ntpd

zeljko zeljko at holobit.net
Wed Nov 2 14:38:35 CET 2011


On Wednesday 02 of November 2011 11:23:10 michael.vancanneyt at wisa.be wrote:
> On Wed, 2 Nov 2011, Jonas Maebe wrote:
> > Marco van de Voort wrote on Wed, 02 Nov 2011:
> >> The point was just some encouragement to look further than the immediate
> >> need though, and keep the time call relatively cheap. That doesn't
> >> exclude being correct, it just means a more elaborate implementation.
> > 
> > I do not think that reporting the time correctly taking into account the
> > current time zone and daylight savings time is a function that needs to
> > be treated as performance-critical.
> 
> Under some (not so uncommon) circumstances it is, e.g. for logging
> facilities. Our own eventlog facility would suffer from this.
> 
> >> But harddisk latency can easily be in the half a second to second
> >> magnitude (and then I don't even count spindowns, and am I accessing
> >> directories that I continously access).
> > 
> > If you are stat'ing that file for changes all the time, either the result
> > will be cached or the hard drive won't spin down. And stat'ing a file
> > will not take half a second when done repeatedly.
> 
> I tested this yesterday, using the following sequence:
> 
> fpGettimeOfDay();
> if UseStat then
>    fpStat('/etc/timezone');
> fpGetTimeOfDay();

Please see results about Now() and something that I've mentioned about 
deprecitation of gettimeofday().According to this test, current 
fpgettimeofday() is crap when compared with clock_gettime() (kernel) or libc 
calls (I've copied scenario from kylix sysutils).

*Kernel clock_gettime() NowReal() with 10000000 calls = 4870 ms 
**Libc gettimeofday()+localtime_r() with 10000000 calls = 5085 ms 
***RTL Now() with 10000000 calls = 7659 ms   ?!?!?!? Slowest !?!?


Simple program is attached. Maybe I've added something wrong, but you can 
correct me if I'm wrong.

zeljko


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20111102/68ef74c4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unixclocks.lpr
Type: text/lazarus-project-source
Size: 2494 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20111102/68ef74c4/attachment.bin>


More information about the fpc-devel mailing list