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.
They are not really used to time execution times btw, but more to rate limit
certain events to xx per second. The events can die out for hours however
(if the machine is stopping for maintenance) Strictly speaking that carries
a monotonous time requirement, but these are of the kind where a trip once
an year doesn't matter.
Twice a year. Anyway: a function that reports the local time is simply
the wrong tool for the job if you need a "mostly" monotonic timer that
you can query at a high frequency. It may work (and apparently it does
for you), but instating a plugin architecture just to be able to keep
using it for that purpose is the wrong approach as far as I am
concerned.
And even if it is eventually transformed into a pluggable API, fixing
it now does not require this plug-in architecture to exist, nor does
fixing it make it harder to transform it into a pluggable API
afterwards.
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.
In Delphi, for timing of short intervals, typically queryperformance counter
+ family is used, but iirc these can't measure longer intervals and are very
imprecise the too (since the CPU frequency might change)
For longer intervals you can use gettickcount/gettickcount64 on
Windows and fpgettimeofday on Unix. I'm not opposed at all to add some
kind of extra "return a monotonic clock value" function somewhere.
In our previous episode, Jonas Maebe said:
If you are in a case where you do want a high precision timer that is only
adjusted once to the system's timezone (namely when the program was
started), then I think it is quite reasonable if the RTL does not provide
such functionality in a standard call.
Not entirely related to the discussion,
It is related as far as I am concerned, because the above is how Now()
currently works on Unix and as far as I understand, you don't want it
to be fixed using a straightforward stat/update check because that may
reduce the performance/rate properties of that call.
but I don't see that at all. There
is a reason why libc has monotonous time functions.
Yes, but they are presumably not based on timezone information because
that inherently defeats the monotonic property.
Jonas
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
