TimerInit(), Int versus Float. (?)

[MvGulik]

I wonder why TimerInit() is returning a Float instead of a Int.

As: Windows, as in 'QueryPerformanceCounter', is returning it as a Int. (LARGE_INTEGER)

So:

If AutoIt is not using 'QueryPerformanceCounter' to get the target value. What is it using? (or: additional info on reason(s) for it to be a float)

If AutoIt is using 'QueryPerformanceCounter' ... The only thing that makes sense to me here is that TimerInit() was implemented before 64bit value support where implemented. (in which case the question comes down to 'why not update TimerInit() to make use of the 64bit value support.)

As Valiks closing comment on ticket 2008 seems to be related to TimerDiff() (which was not the subject of the ticket) its not helping in this matter.

The general benefits would be minor. Seemingly more consistency in the returned TimerInit() data(type) in relation to windows 'QueryPerformanceCounter' and a little speedup in special AutoIt timer scripts. (Int versus float math. ... assuming of course.)

Ticket: #2008

MSDN: QueryPerformanceFrequency

Edited September 30, 2011 by iEvKI3gv9Wrkd41u

[jvanegmond]

In the v3.1.0 download of the AutoIt source code, the function TimerInit is in src/script_misc.cpp. It uses QueryPerformanceCounter on a __int64 and converts that to double. There are no documented changes in the History page for TimerInit/TimerDiff after 2004.

Edited September 30, 2011 by Manadar

[MvGulik]

aha, thanks.

Additional data: (pulled from online beta history)

3.1.0 (7th February, 2005) (Release)

- Changed: (Internal) Variant rewrite (now handles int32, int64, double, string, HWND data)

3.0.102 (4th August, 2004) (Release)

- Changed: TimerStart() renamed to TimerInit(). TimerStop() renamed to TimerDiff()

3.0.70 ... _{(last date on: v3.0.75 (30th November, 2003))}

- Added: TimerStart(), TimerStop()

So it seems as I anticipated. ...

Edited September 30, 2011 by iEvKI3gv9Wrkd41u

[MvGulik]

Added it as Request to tracker. #2025

[trancexx]

VarGetType is great when used with sense. Used otherwise makes normal people wish it wouldn't exist at all.

[BrewManNH]

I'm not sure if this would be of any help in understanding what the timer functions are returning, but this article might help explain why it comes back as an float rather than an int.

The value retrieved is an integer, but that's meaningless unless you know what the frequency of the counter is. The returned counter will give you a figure of how many ticks it counted, take that number and divide it by the ticks per second (the frequency) to get the time, this value is going to be a float.

Edited October 2, 2011 by BrewManNH

[Valik]

From the ticket I just closed:

If you use the return value from TimerInit() for anything other than an opaque handle to be passed to TimerDiff() then you are asking for trouble. Therefore the type is irrelevant. Ticket closed.

Edited October 2, 2011 by Valik

[MvGulik]

Your closing it based on a presumption how I (or others) might be (mis)using it ?

(I personally don't even use TimerDiff() in the case where I work directly with the TimerInit() data.)

Would have been nice if you could have used one of the reasons I mentioned for the closure reason ...

The general benefits would be minor. Seemingly more consistency in the returned TimerInit() data(type) in relation to windows 'QueryPerformanceCounter' and a little speedup in special AutoIt timer scripts. (Int versus float math. ... assuming of course.)

But than I probably should have included them (as text) in the ticked if I read you right.

O well.

Edited October 2, 2011 by iEvKI3gv9Wrkd41u

[Beege]

Your closing it based on a presumption how I (or others) might be (mis)using it ?

I dont think its just that. Your asking them to change two functions for something that you even said "the benifits are minor". Plus since you can use DllCall() and 'QueryPerformanceCounter', theres already an alternative to using the autoit timer functions. Asking them to make changes that produce minor benifits and already has alternatives, is sure to get shot down.

[Valik]

I closed it because it's a fucking stupid request. You are trying to attach meaning to the return value of TimerInit() that we do not guarantee. The return value of TimerInit() should be treated as an opaque handle. That means the underlying type is irrelevant. If I want to make it a string that's my choice as a developer of AutoIt. All I have to ensure is that TimerDiff() still accepts that data and that TimerDiff() returns the calculated difference. There are no other guarantees about how either function works.

I'm going to go adjust the documentation accordingly. Now shut the fuck up about this absolutely stupid and pointless subject.

Edited October 3, 2011 by Valik

[MvGulik]

Now shut the fuck up about this absolutely stupid and pointless subject.

Yea yea, I know, or else you just ban me for amusing you to much.

[Left topic.]

[wraithdu]

FYI, if you need a guaranteed return type, use _Timer_Init() and _Timer_Diff() from Timers.au3. They are wrappers for QueryPerformanceCounter and Init returns an int64.