What should be returned by the reltime() call? If Vim script only
handles "int" types, the values returned are apparently inconsisent.
Am I missing something, or is reltime() on windows currently useful
only for short delta times?
I'm considering making a patch that will roll the amount of the "low
part" into the "high" part, but of course that might invalidate the
"high" part. An alternative would be to return a list of 4 "int"s.
P.S. Internally, QuadPart is used so I guess that must be correct.
On 6/11/06, George V. Reilly <[EMAIL PROTECTED]> wrote:
(Moving the non-developer list to BCC.)
Eric Arnold wrote:
> I'm trying to understand what I'm seeing with the msec timing on win32
> (cygwin). Inside the debugger, I'm seeing:
>
> (gdb) p tm_delta
> $1 = {u = {LowPart = 2434313347, HighPart = 896}, {LowPart = 2434313347,
> HighPart = 896}, QuadPart = 3850725010563}
> (gdb) n
> 180 n1 = tm_delta.HighPart;
> (gdb)
> 181 n2 = tm_delta.LowPart;
> (gdb) p n1
> $4 = 895
> (gdb) p n2
> $2 = -1860653949
>
> And in Vim:
>
> :echo reltime()
> [895, -162159878]
>
>
> So is this a bug? Internally, the low part of the proftime_T
> structure is positive, and it shows up externally as negative. I
> checked, and as far as I can tell, the LowPart is a win32
> LARGE_INTEGER, which is 8 bytes, which is trying to be stuffed into a
> "long" which is 4 bytes. I think the right answer is a "double", but
> I'm not real sure about how win32 stuff works (since WhyTF has it
> defined a special LARGE_INTEGER type?).
If you go look at the definition of LARGE_INTEGER in the Windows
headers, you'll see that it's a union of a 64-bit integer (QuadPart) and
two 32-bit integers (HighPart, LowPart). It has to be a LARGE_INTEGER
because the profiler uses QueryPerformanceCounter() to get the most
accurate results, and that's what QPF uses. LARGE_INTEGERs date from the
early 90s, when many compilers didn't support intrinsic 64-bit operations.
The value you actually want is QuadPart. However, this is calibrated in
system-dependent ticks, which are generally, but not always, equal to
the frequency of your CPU. To convert QuadPart to milliseconds, multiply
QuadPart by 1000/Frequency, where Frequency is the result of a call to
QueryPerformanceFrequency().
--
/George V. Reilly [EMAIL PROTECTED]
http://www.georgevreilly.com/blog
