benchmark similar alternative AutoIT commands with an AutoIT script

[Imbuter2000]

I made an universal AutoIT function to calculate the time taken by similar alternative AutoIT commands, in order to compare the different times and chose the fastest or more efficient one:

Func chrono($command)
     ProcessSetPriority("AutoIt3.exe", 5)       ; to set the engine to realtime priority
     local $timer = TimerInit()            ; initialize timer
     local $timer_null_command = TimerDiff($timer)     ; measure the net time without the command (if any)
     execute($command)    ;  run the command to be time-measured
     local $timer_post = TimerDiff($timer)     ;  stops the chronometer
     return = return Int($timer_post-$timer_null_command)     ; return the net time taken by the command
EndFunc

Do you think that the ProcessSetPriority("AutoIt3.exe", 5) and the $timer_post-$timer_null_command are a good method to obtain more precision?

Note: I then enhanced the script by calculating with a cycle the average time of the last 5 repetitions of the command with a stable (+-15%) time result between the lowest and highest value of the serie (the 5 last values).

Edited January 23, 2013 by Imbuter2000

[Melba23]

Imbuter2000,

Certainly using ProcessSetPriority("AutoIt3.exe", 5) is fraught with danger - as the Help file makes clear. MSDN has this to say about setting "REALTIME_PRIORITY":

You should almost never use REALTIME_PRIORITY_CLASS, because this interrupts system threads that manage mouse input, keyboard input, and background disk flushing. This class can be appropriate for applications that "talk" directly to hardware or that perform brief tasks that should have limited interruptions.

No AutoIt script (or even most commands) could ever be considered as a "brief task" in the sense of that snippet as far as I am concerned.

M23

[guinness]

I would say this is a bad approach to working out execution time of native functions, also your Return line is incorrectly formatted.

[Imbuter2000]

You should almost never use REALTIME_PRIORITY_CLASS, because this interrupts system threads that manage mouse input, keyboard input, and background disk flushing.

"Interrupts" = pauses?

I would accept to put them in pause for 0-5 seconds in order to obtain perfect benchmark/time comparisons.... and I don't expect risk of a system crash because I mostly test single commands or very short functions without loops...

I would say this is a bad approach to working out execution time of native functions, also your Return line is incorrectly formatted.

I can't see a better approach and yes, I wrongly repeated the "return" fastly recostructing by memory my script... oops...

Edited January 24, 2013 by Imbuter2000

[guinness]

I don't think there is any "good" approach. I'm just not keen on using Execute when I don't have to.

[Melba23]

Imbuter2000,

to put them in pause for 0-5 seconds

I would most certainly not class that period as "brief" in computing terms.

If we take the example of a GUIRegisterMsg handler, I work to a maximum of 500ms within it before returning - and ususally aim to get well below that figure. Several seconds is an eternity for a PC and you really do run the risk of crashing the system - and you may well be getting false results anyway as the system is unable to properly respond to the commands that you are sending.

But you carry on with your tests by all means - all I want to do is to warn you and any others who might want to do the same thing of the possible pitfalls.

M23