On Wed, 2 Nov 2011, michael.vancann...@wisa.be wrote:
On Wed, 2 Nov 2011, zeljko wrote:
On Wednesday 02 of November 2011 11:23:10 michael.vancann...@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
and anyway:
fsb: >fpc /home/michael/unixclocks.lpr
Fatal: Can't find unit Libc used by unixclocks
Fatal: Compilation aborted
Error: /usr/local/bin/ppcx64 returned an error exitcode (normal if you did not
specify a source file to be compiled)
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
