TimerInit() handle

[BinaryBrother]

Is the TimerInit handle destroyed if you overwrite the originating variable? I doubt it... but that would mean there's no way to destroy the Timer handle natively. I've seen Timer UDFs, but I was just curious as to the repercussions of creating hundreds of thousands on timer handles, by debugging certain things for a while to get average times.

This is another time-wasting question that doesn't have any real goal or purpose, outside satisfying my curiosity! So I figured chat was a good place for it, once again. ^.^

Doesn't this create Timer handles that aren't getting destroyed? Does it hurt anything to use timers at the beginning of a script and never use them again? Aren't they just sitting there running?

While 1
     $TimerHandle = TimerInit()
     $TimerDiff = TimerDiff($TimerHandle)
WEnd

[JohnOne]

As I understand it, TimerInit() does not create a handle, rather a current timestamp.

TimerDiff() creates another, and returns the difference.

[czardas]

Doesn't this create Timer handles that aren't getting destroyed? Does it hurt anything to use timers at the beginning of a script and never use them again? Aren't they just sitting there running?

While 1
     $TimerHandle = TimerInit()
     $TimerDiff = TimerDiff($TimerHandle)
WEnd

 

No, you are overwriting both variables in every loop with that code, plus what JohnOne said.

Edited January 27, 2014 by czardas

[BinaryBrother]

Ahh! I hadn't actually tried looking at what TimerInit() returned. It returns the same as _Timer_Init() [uDF included with AutoIt 3.3.10.0], which is just the current timestamp.

The documentation makes it sound so mysterious, saying that you shouldn't do anything with the TimerInit() return and it should be treated as a handle...

http://screencast.com/t/X5bjXCk6s0yg

Anywho, that perfectly answers my question. I could have figured that one out if I had just checked the return from TimerInit()!

Thanks JohnOne & czardas!

Edited January 27, 2014 by BinaryBrother

[BrewManNH]

TimerInit does not return a timestamp, it returns what Valik termed as an opaque handle, TimerDiff uses that handle to calculate the difference in time between the Init and the Diff.

[Richard Robertson]

He didn't say it is, he said it should be treated as. It is still not a real handle because that would cause a horrible memory leak if all those handles were created and not freed. Notice there is no TimerDestroy function.

[BrewManNH]

He didn't say it is, he said it should be treated as.

I'm not sure what it is you're saying here.

It is still not a real handle because that would cause a horrible memory leak if all those handles were created and not freed. Notice there is no TimerDestroy function.

That's why he called it an opaque handle, as in it's not a handle but a pointer to something else. But it's not a timestamp as others were saying above, which is what I was trying to point out. This stuff is above my ability level, I just wanted people to not get the wrong idea as to what timerinit returns.

[JohnOne]

I'm sure there's a lot of voodoo under the bonnet, but it's essentially a timestamp at the user end.

[BrewManNH]

Even if it were a timestamp, there's no way to use it as one. You can't subtract two timerinits and get a time difference, at least not directly in a format that makes sense.

[JohnOne]

Probably not, because I don't know how it is implemented, but I don't need to, Timerdiff deals with that.

One might have a definition of what a standard timestamp might be, but however you cook it Timerdiff is a timestamp for Timerinit, regardless of it's type.

[BinaryBrother]

Sorry for not validating that it was a valid timestamp, I just glanced at it.

Jesus... I had forgotten how blunt Valik was...

Edited January 27, 2014 by BinaryBrother

[JohnOne]

wiki defines a timestamp as "a sequence of characters or encoded information identifying when a certain event occurred, usually giving date and time of day, sometimes accurate to a small fraction of a second"

If that is not what TimerInit is, I'll eat my undercrackers.

[funkey]

#include <WinAPISys.au3>

Global $iStart = TimerInit()
Global $iStart2 = _WinAPI_QueryPerformanceCounter()
ConsoleWrite("TimerInit: " & $iStart & @LF)
ConsoleWrite("QueryPerformanceCounter: " & $iStart2 & @LF)

Sleep(2000)
ConsoleWrite(TimerDiff($iStart2) & @LF)
ConsoleWrite((TimerInit() - $iStart2)*1000 / _WinAPI_QueryPerformanceFrequency() & @LF)

Edited January 27, 2014 by funkey

[Mat]

It's never actually documented what the return type is. It could change in the next release to something completely different, so any code you write that uses the return value for anything other than TimerDiff could be broken and it wouldn't even be mentioned in the changelog.

That's why Valik said to treat it as a handle: something which only has meaning internally.

[czardas]

I agree with JohnOne. If it was not returning some kind of a time stamp, it simply could never work. It's irrelevant what data type is being used.

Edited January 27, 2014 by czardas

[trancexx]

It's returning simple timestamp but read what Mat said, it sums it up perfectly.