On Wednesday 02 of November 2011 16:12:49 you wrote: > On Wed, 2 Nov 2011, zeljko wrote: > > On Wednesday 02 of November 2011 15:47:46 you wrote: > >> On Wed, 2 Nov 2011, zeljko wrote: > >>> On Wednesday 02 of November 2011 14:53:05 you wrote: > >>>> You must do also a localtime_r after this call. > >>>> clock_gettime returns the same time as gettimeofday. > >>> > >>> But point IS in comparing clock_gettime() vs. gettimeofday() which is > >>> used by fpgettimeofday(). I don't see localtime_r() calls in current > >>> RTL Now(). > >> > >> Ok. > >> > >> It turns out that Now() was doing a fpGettimeofday (for time) and a > >> fptime (for date), which is of course really stupid. > > > > Yes, I saw that after posted example. > > > >> I improved that (it does one call only). So, new stats, 64-bit, no > >> optimizations: > >> > >> sb: >./unixclocks > >> RTL Now() with 10000000 calls = 3698 ms > >> Kernel clock_gettime() NowReal() with 10000000 calls = 6564 ms > >> > >> Revision 19572. > >> > >> The time is now less than the Libc time you posted (5085ms). > > > > I don't care about libc timing, but why clock_gettime() is so slower now > > ? It is called only once in my example. Are you sufre that RTL now() > > returns correct date/time ? > > Yes. Of course I tested that first :-) > > I assume your version is slower because you call epochtolocaltime twice, > for instance. > > If I remove the second call (it's not needed anyway) then > > RTL Now() with 100000 calls = 2337 ms > Kernel clock_gettime() NowReal() with 100000 calls = 2344 ms > > >> I can't test the libc version, but if you'd care to re-test using the > >> above revision of unix/sysutils.pp, and post the results, I'd be > >> grateful. > > > > Sorry, but I don't want to use 2.7.1 until it's useable. > > I attached the changed file.
No need to test libc version in this case it's timing will be slower anyway because of 2 calls a) gettimeofday() localtime_r() ... so it's not important at all. That sysutils.pp now looks pretty clean, and again: *I hope* that this changes will be merged to 2.4.5 and 2.6.0 :) ... and of course ReReadTimeZone() (or what was that name...) as solution for issue ... http://bugs.freepascal.org/view.php?id=20604 zeljko
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel