Followers 0

# AutoIT Speed Tester

## 26 posts in this topic

Posted (edited)

Well maybe it's me (it surely is) but I like my AutoIT code when it's FAST.

So here's a little program I whipped up in about an hour.

AutoIT_Speed.au3

Updated 19Aug2007 with more comments and more test results

It will execute commands of your choice through two loops, 20 packs of 9999 iterations to be precise.

Making two loops increased the reliability of the reading (since it seems the first iteration is really slow because of cache issues and what not).

For example, you could compare

`\$Val = \$Val +1`

to ...

`\$Val += 1`

(in this case, the obvious winner is \$Val += 1 but it isn't always so evident)

The code is as simple as can be, I guess if you don't get it than it's not for you

In any case, the results you get might make you change your programming habits!

If you do a lot of looping then I suggest you try out the commands in those loops and see what's better.

Good luck!

EDIT:

It's been brought to my attention by chris95219 that GetTickCount() cannot be properly timed.

Also if you use the \$i and \$j variables in your code (both loop counters) you will obviously get incorrect results!

TESTED BY YOURS TRUELY:

1. For/Next loops are champions. Try not to use While/Wend or Do/Until

2. If \$Val is faster than If \$Val = 1 or \$Val = TRUE

3. If \$Val = 1 is faster than \$Val = TRUE

4. If Not \$Val is faster than If \$Val = 0 or \$Val = FALSE

5. If \$Val = 0 is faster than If \$Val = FALSE

6. < and > are faster than =, >= or <= (Wow!)

7. \$i += 1 is faster than \$i = \$i + 1

\$i -= 1 is faster than \$i = \$i - 1

\$i *= 1 is faster than \$i = \$i * 1

\$i /= 1 is faster than \$i = \$i / 1

8. If doing a lot of verifications on a single variable:

Switch is fastest, Select is second (but slow) and If is slowest.

9. If \$Val is a string, If Not \$Val is faster than If \$Val = ""

If \$Val is faster than If \$Val <> ""

10. When doing binary operations, If \$Val -128 > 0 is twice as fast

as If BitAnd(\$Val, 128).

11. Using Hex numbers is faster than using decimal numbers

12 Replacing dec/hex numbers by variables slows down execution. Use hex/dec numbers when possible

13. Longer variable names = longer execution time. Keep variable names short and clear!

14. StringRegExpReplace() is slower than StringReplace(). Use it only if necessary!

15. StringRegExp() is slower than StringInStr(). Use only if necessary!

16. Opt("ExpandEnvStrings",1) makes \$Val = "%TEMP%" faster than \$Val = EnvGet("temp")

or \$Val = @TempDir

17. \$Val = @TempDir is faster than \$Val = EnvGet("temp")

18. Opt("ExpandVarStrings",1) makes \$Val = "\$String\$" slightly faster than \$Val = \$String

19. However \$Val = "@TempDir@" is slower than \$Val = @TempDir (go figure!)

Edited by Celeri
Cahkhene25 likes this

##### Share on other sites

Posted

Nice test...

(but these results would be inaccurate if AutoIt uses GetTickCount() internally for it's Timer functions...)

##### Share on other sites

Posted

Nice test...

(but these results would be inaccurate if AutoIt uses GetTickCount() internally for it's Timer functions...)

Wow, I've never used GetTickCount()

I'll add a line to the first post just in case

BTW there are other functions that can't really be tested by my program.

There's "Exit" (duh!) and "Return".

I guess you could call a function and return but you can never test "Return" all alone.

Which makes me think ... Hmmm what's fastest?

```SetError(\$ErrNum)
Return```

Or

`Return SetError(\$ErrNum)`

##### Share on other sites

Posted (edited)

`SetError(\$ErrNum)<BR>Return`

Or

`Return SetError(\$ErrNum)`

On my computer Return SetError(\$ErrNum) is marginally slower than SetError(\$ErrNum)

Return

But by so little that there's nothing to write home about

Edited by Celeri

##### Share on other sites

Posted

It would be pretty cool if you used an input box or 'load file' to let the user choose the file/expression to test it's speed

##### Share on other sites

Posted (edited)

Hi Celeri, thanks for sharing your experiments here, there has been a few other threads dealing with the differing performance of various AutoIt loops and operators - still you added quite a few subtle ones I haven't come across before ("If Not \$Val" being faster than "If \$Val = 0" for an example).

Sunaj

EDIT: Interesting thing here is that learning these basic tricks of the trade is a rather good idea since they hold true (on some level at least) not just for AutoIt but also for Java, C++ and more (see: http://www.codeproject.com/cpp/C___Code_Optimization.asp and http://www.javaworld.com/javaworld/jw-04-1...ze.html?page=1)

TESTED BY YOURS TRUELY:

1. For/next loops are champions. Try not to use While/Wend or Do/Until

2. If \$Val is faster than If \$Val = 1 or \$Val = TRUE

3. If \$Val = 1 is faster than \$Val = TRUE

4. If Not \$Val is faster than If \$Val = 0 or \$Val = FALSE

5. If \$Val = 0 is faster than If \$Val = FALSE

6. < and > are faster than =, >= or <= (Wow!)

7. \$i += 1 is faster than \$i = \$i + 1

8. If doing a lot of verifications on a single variable:

Switch is fastest, Select is second (but slow) and If is slowest.

Edited by Sunaj

##### Share on other sites

Posted (edited)

It would be pretty cool if you used an input box or 'load file' to let the user choose the file/expression to test it's speed

I'll see what I can do

However this might require a thinking cap! --> it implies a self-modifying code. But I'm all for it if it is possible.

One way this could be done is by #including a file which contains bunch of UDFs to be speedtested. The user would then have to specify which UDF to speed test. (i.e.: _speedtest1() )

EDIT:

In retrospect, it can be done with Execute() but since you're going to have to code it anyways, an input box or an input file is in my opinion not the best way to go. Don't forget this program tests code snippets that sometimes requires preset variables and/or calling parameters, which is way beyond Execute() (I was lead to believe it is used to return the result of a simple expression like 1 + \$B [the function returns the equal part of the formula and \$B in this case must be previously declared]). In any case if it's what you want it's easy to add two lines to the code:

Put this at the start:

`\$Input_CODE = InputBox("AutoIT Speed Test","Enter command to test it's speed"&@CR&"(One line only!)")`

Put this line at line after the "For \$j = 1 To 9999" and the comments that follow

`\$Result = Execute(\$Input_CODE)`

You can ConsoleWrite the variable \$Result after the loops if you want to see what happened.

There are also issues with syntax checking but if it's used by someone who knows his stuff than I guess it's OK. In any case I commented every line so that unexperimented users can take a peek and understand how this works. If any of you modifies the code (make it faster?) than I'd really appreciate seeing what you did

Edited by Celeri

##### Share on other sites

Posted

Hi Celeri, thanks for sharing your experiments here, there has been a few other threads dealing with the differing performance of various AutoIt loops and operators - still you added quite a few subtle ones I haven't come across before ("If Not \$Val" being faster than "If \$Val = 0" for an example).

EDIT: Interesting thing here is that learning these basic tricks of the trade is a rather good idea since they hold true (on some level at least) not just for AutoIt but also for Java, C++

Thanks! I started learning C++ but I'm lazy and I have a limited amount of time.

AutoIt's learning curve is really, really low

Although there's a few quirks here and there but you get used to it.

I'll keep on comparing - if any of you has anything interesting, post it and I'll add it to the first post

##### Share on other sites

Posted

i would like to see differences in speed/performance between autoit & c# at handling large _arrays (sorting and searching).

##### Share on other sites

Posted

i would like to see differences in speed/performance between autoit & c# at handling large _arrays (sorting and searching).

Since AutoIt is an interpreted language (as compared to a compiled language) the difference will probably pretty big (not in favor of AutoIT3). Hey anyone here can prove me wrong?

##### Share on other sites

Posted (edited)

Since AutoIt is an interpreted language (as compared to a compiled language) the difference will probably pretty big (not in favor of AutoIT3). Hey anyone here can prove me wrong?

C# is much much much faster than AutoIt. In fact C# is probably about 90% the speed of C++.

Edited by chris95219

##### Share on other sites

Posted (edited)

C# is much much much faster than AutoIt. In fact C# is probably about 90% the speed of C++.

Mind you, it depends.

If you're working with files and file transfers in AutoIT3, the difference in speed with C# or C++ will be minimal since the program will be dependent upon Harddrive latency. I once made a cleaning program in AutoIT3 and it was up there with CCleaner in terms of speed

Edited by Celeri

##### Share on other sites

Posted

The thing is, you have to remember what AutoIt is doing behind the scenes. Your AutoIt program is being overlayed on a C++ program.

```\$x = TimerInit()
for \$i = 0 to 1000
random(0, 65535)
Next
\$y = TimerDiff(\$x)
MsgBox(0, "", \$y)```

This is taking anywhere from 9 to 60 ms on my computer - that is very slow. Whereas you can do that in C# or C++ in much much less time.

##### Share on other sites

Posted

The thing is, you have to remember what AutoIt is doing behind the scenes. Your AutoIt program is being overlayed on a C++ program.

```\$x = TimerInit()
for \$i = 0 to 1000
random(0, 65535)
Next
\$y = TimerDiff(\$x)
MsgBox(0, "", \$y)```

This is taking anywhere from 9 to 60 ms on my computer - that is very slow. Whereas you can do that in C# or C++ in much much less time.

That much is clear

However my mom can program AutoIT3, but I doubt she'd get along with C++ or C# ahahahah

##### Share on other sites

Posted (edited)

That much is clear

However my mom can program AutoIT3, but I doubt she'd get along with C++ or C# ahahahah

Ok so it looks I'm going to have to reply to myself to get any input here

So anyways, just discovered 3.2.6.0 is out and it boasts a 30%-40% speed increase ... we'll be the judge of that

<LI>Changed: General performance improvements (currently around 30-40% over 3.2.4.9)

http://www.autoitscript.com/forum/index.php?showtopic=51967

I'll keep you posted with some observations in the following days.

See ya!

Edited by Celeri

##### Share on other sites

Posted (edited)

I think this is a really good idea for testing AutoIt's limits. This will help a lot of people!

Edited by sandman

##### Share on other sites

Posted (edited)

Tested and so far it's true - 3.2.6.0 is very much FASTER.

I suggest you upgrade and test again

P.S.: Thanks for the encouragement Sandman Where do I apply for the toaster?

Edited by Celeri

##### Share on other sites

Posted

1. For/next loops are champions. Try not to use While/Wend or Do/Until

But how can we change a While statement like when you want to get gui msg like this one:

```While 1
\$msg = GUIGetMsg()

Select
Case \$msg = \$Button1
Func1()
Endselect
Wend```

and subtitute it for a For/Next ???

##### Share on other sites

Posted

But how can we change a While statement like when you want to get gui msg like this one:

```While 1
\$msg = GUIGetMsg()

Select
Case \$msg = \$Button1
Func1()
Endselect
Wend```

and subtitute it for a For/Next ???

You shouldn't worry about that. A msgloop doesn't run that often for a change to be significant.

@OP

Autoit doesn't use getickcount, but queryperformancecounter, last time i checked, which is high-resolution and ok for testing.

##### Share on other sites

Posted

@OP

Autoit doesn't use getickcount, but queryperformancecounter, last time i checked, which is high-resolution and ok for testing.

I don't think the OP will be too concerned, he hasn't been online in nearly 3 years, as this is a 5 year old topic brought back from the dead.

##### Share on other sites

Posted

I don't think the OP will be too concerned, he hasn't been online in nearly 3 years, as this is a 5 year old topic brought back from the dead.

Ah lol, didnt notice

##### Share on other sites

Posted

But how can we change a While statement like when you want to get gui msg like this one:

Like this:

```; A simple custom messagebox that uses the MessageLoop mode
#include <GUIConstantsEx.au3>
_Main()
Func _Main()
Local \$YesID, \$NoID, \$ExitID, \$msg
GUICreate("Custom Msgbox", 210, 80)
GUICtrlCreateLabel("Please click a button!", 10, 10)
\$YesID = GUICtrlCreateButton("Yes", 10, 50, 50, 20)
\$NoID = GUICtrlCreateButton("No", 80, 50, 50, 20)
\$ExitID = GUICtrlCreateButton("Exit", 150, 50, 50, 20)
GUISetState() ; display the GUI
for \$i = 0 to 0
\$msg = GUIGetMsg()
Select
Case \$msg = \$YesID
MsgBox(0, "You clicked on", "Yes")
Case \$msg = \$NoID
MsgBox(0, "You clicked on", "No")
Case \$msg = \$ExitID
MsgBox(0, "You clicked on", "Exit")
Case \$msg = \$GUI_EVENT_CLOSE
MsgBox(0, "You clicked on", "Close")
EndSelect
if \$msg = \$GUI_EVENT_CLOSE Or \$msg = \$ExitID then ExitLoop
\$i -= 1
next
EndFunc   ;==>_Main```

##### Share on other sites

Posted

Well it's been so long since this topic was originally started, the timing stuff first mentioned might not even be relevant now... Maybe it was a good thing to dig this up from the grave, since performance issues now might not be the same as performance issues back in 2007

Although some of the things mentioned would still apply, since they are dealing with letting more magic happen in the interpreter's internal workings instead of in the code being interpreted... Some things I should mention is with the StringRegExp functions, those now seem about twice as fast as their non-regex counterparts for searching large amounts of text with a simple regex pattern. But as a rule-of-thumb in any interpreted language, if you can get the interpreter to do more work by having your code do less work (like \$i += 1 instead of \$i = \$i + 1) then it'll run faster. (although it isn't going to be that much faster!)

##### Share on other sites

Posted (edited)

Hey, just read this and decided to share something interesting about speeding up code.

Also, sorry about bumping this, but i think its (still in 2013) really interesting.

Story / Problem:

I discovered this lately when i was filling a listview of 19 collumns with the > 30,000 entries of my sql data base.

`GUICtrlCreateListViewItem("nineteen|collumns|full|of|data", \$handle)`

If the entry had 'success', 'failure', 'downloaded', etc... in the status collumn, the entry would get colored.

`_GUICtrlListView_SetItemColor(\$handle,\$i,0x88ff88) ; green`

This process took over 40 minutes on my notebook, so i was looking for a solution to speed up the whole thing.

Solution:

I found this when i was trying to make the GUI more user friendly. I hid and disabled all the controls from the GUI and set the cursor to waiting, both returning to normal when the Listview was finished.

```GUISetCursor(15, 1)
GUICtrlSetState(\$handle, \$GUI_DISABLE + \$GUI_HIDE)
; ...
; ...
GUISetCursor(2, 0)
GUICtrlSetState(\$handle, \$GUI_ENABLE + \$GUI_SHOW)```

After these modifications, the whole process took only 2 minutes, so you can actually increase the performance by 2000% !

TL/DR:

Hiding a Listview control while filling huge amounts of data into it drastically increases performance.

-----

And sorry for my bad english

Edited by Brobbl

##### Share on other sites

Posted (edited)

TL/DR:

Hiding a Listview control while filling huge amounts of data into it drastically increases performance.

This is precisely what these are used for (without having to disable or hide the control):

```_GUICtrlListView_BeginUpdate()
_GUICtrlListView_EndUpdate()```
Edited by wraithdu

## Create an account

Register a new account