the internal-time-units-per-second pseudo-constant is documented as =
being 10_000_000 on Ms-windows.
1. actual values returned by get-internal-run-time only differ by steps =
of 15.625 milliseconds (i.e. 156250).
2. actual values returned by get-internal-real-time differ by either =
15.0 or 16.0 milliseconds (i.e. 150000 or 160000).
What's the "value" of having an advertised value of 10_000_000 which =
(at least) I cannot make sensible use of?
Am I missing a MS-windows configuration switch?
All I see is that every call to these functions is likely to allocate a =
bignum, while granularity is in fact much less.
INTERNAL-TIME-UNITS-PER-SECOND of 64 (for 15.625ms increments) would =
BTW, I reported a similar problem to the Jakarta/JMeter list back when =
I observed that all reported performance measurements where in fact in =
steps of (I interpolated) 15.625 ms increments: times spent were =
reported as 15, 16 or integer multiples of 15.625 ms.
Observed on a MS-windows-2k machine.
Get latest updates about Open Source Projects, Conferences and News.