autoit perfectionism at it's best!

[TheAutomator]

19 minutes ago, Musashi said:

I' am not sure if this is a robust test ?

Variation 2 takes twice as long.

Yeah exactly, that's proof

[TheAutomator]

Function arguments that are not ByRef are copies of the original argument send to the function right?
so wouldn't using ByRef be better for memory management and speed most of the time? Especially with large arrays or big strings that need to be passed around.
A lot of examples and functions in autoit don't use byref by default.

[Musashi]

2 hours ago, TheAutomator said:

Function arguments that are not ByRef are copies of the original argument send to the function right?

[...]

A lot of examples and functions in autoit don't use byref by default.

Yes, but ByRef is not always required for arrays to avoid local copies ! This is described very comprehensively in Global,_Local,_Static_and_ByRef

Excerpt :

"It was mentioned earlier that when you pass variables to functions AutoIt makes local copies of these variables unless you declare that they are to be passed ByRef. In the special case of arrays, which are typically larger than a simple variable, AutoIt will only make a local copy if you change the array inside the function - merely accessing the array will use the original version. So passing the array ByRef is only advantageous if you intend to modify the array within the function - however, it does no harm to force the issue by using the keyword. "

Full text :

Spoiler

Passing variables as parameters using ByRef

When you call a function in AutoIt, you can pass parameters to the function by including them in the parentheses following the function name like this - Function(Parameter_1, Parameter_2). Passing variables in this way means that you can use variables that have been declared as Local within other functions. Note that the parameters are automatically declared as Local variables within the called function and so do not need to be declared again in the code.

Variables can be passed as parameters to a function in 2 ways:

By Value - This is the default. The parameter is treated as a Local variable within the function to which it is passed and any changes made to it are lost when the function ends. So no changes are made to the Local variable within the original function.

By Reference - This is used when ByRef is added before the variable name in the parameter list of the function declaration. Now any changes to the variable made in the function to which it is passed also affect the Local variable in the original function. If you do not understand why this is such a powerful capability, you need to read the Global/Local section again!

Here is a small example to show how parameters are passed when calling a function:

#include <MsgBoxConstants.au3> ; only required for MsgBox constants

Func_A()

Func Func_A()
	; Declare variables
	Local $iVar_A1 = 10
	Local $iVar_A2 = 20
	; And read them
	MsgBox($MB_SYSTEMMODAL, "Read", "Initial read in Func A:" & @CRLF & "Var A1 = " & $iVar_A1 & @CRLF & "Var A2 = " & $iVar_A2)

	; Now pass these variables to another function - we use the names we have already declared in this function
	Func_B($iVar_A1, $iVar_A2)

	; We changed the parameters in Func_B - but nothing happened to the variables in this function
	MsgBox($MB_SYSTEMMODAL, "Read", "Second read in Func A:" & @CRLF & "Var A1 = " & $iVar_A1 & @CRLF & "Var A2 = " & $iVar_A2)
EndFunc   ;==>Func_A

Func Func_B($iVar_B1, $iVar_B2) ; There is no need to declare the variables as parameters are automatically Local in scope
	; Now read these variables - note that they have the same value as the variables in Func_A
	MsgBox($MB_SYSTEMMODAL, "Read", "Initial read in Func B:" & @CRLF & "Var B1 = " & $iVar_B1 & @CRLF & "Var B2 = " & $iVar_B2)

	; Let us change them
	$iVar_B1 = 100
	$iVar_B2 = 200

	; And confirm that they have changed
	MsgBox($MB_SYSTEMMODAL, "Read", "Second read in Func B:" & @CRLF & "Var B1 = " & $iVar_B1 & @CRLF & "Var B2 = " & $iVar_B2)

	; Now return to the other function
EndFunc   ;==>Func_B

As you can see, the Local variables within Func_A are read perfectly by Func_B when passed as parameters, even though they were declared as Local in Func_A. However, although Func_B changes the value of the variables, the values of the original variables within Func_A are not changed.

If we want to change the value of the variables in Func_A from within Func_B, we need to use the ByRef keyword as explained above and illustrated here:

#include <MsgBoxConstants.au3> ; only required for MsgBox constants

Func_A()

Func Func_A()
	; Declare variables
	Local $iVar_A1 = 10
	Local $iVar_A2 = 20

	; And read them
	MsgBox($MB_SYSTEMMODAL, "Read", "Initial read in Func A:" & @CRLF & "Var A1 = " & $iVar_A1 & @CRLF & "Var A2 = " & $iVar_A2)

	; Now pass these variables to another function - but this time we will pass $iVar_A2 By Reference
	Func_B($iVar_A1, $iVar_A2)

	; We changed the parameters in Func_B - this time we see that we have changed $iVar_A2
	MsgBox($MB_SYSTEMMODAL, "Read", "Second read in Func A:" & @CRLF & "Var A1 = " & $iVar_A1 & @CRLF & "Var A2 = " & $iVar_A2)
EndFunc   ;==>Func_A

Func Func_B($iVar_B1, ByRef $iVar_B2) ; Note the ByRef keyword in the function declaration for the second parameter
	; Now read these variables - they have the same value as the variables in Func_A
	MsgBox($MB_SYSTEMMODAL, "Read", "Initial read in Func B:" & @CRLF & "Var B1 = " & $iVar_B1 & @CRLF & "Var B2 = " & $iVar_B2)

	; Let us change them
	$iVar_B1 = 100
	$iVar_B2 = 200

	; And confirm that they have changed
	MsgBox($MB_SYSTEMMODAL, "Read", "Second read in Func B:" & @CRLF & "Var B1 = " & $iVar_B1 & @CRLF & "Var B2 = " & $iVar_B2)

	; Now return to the other function
EndFunc   ;==>Func_B

A couple of more advanced points:

- It was mentioned earlier that when you pass variables to functions AutoIt makes local copies of these variables unless you declare that they are to be passed ByRef. In the special case of arrays, which are typically larger than a simple variable, AutoIt will only make a local copy if you change the array inside the function - merely accessing the array will use the original version. So passing the array ByRef is only advantageous if you intend to modify the array within the function - however, it does no harm to force the issue by using the keyword.

- If you are dealing with a simple variable of considerable size (the text of a file for example) then passing it ByRef is a sensible action. But if you want to make sure that the variable cannot be altered inside the function, you can declare it as Const ByRef in the function definition as shown here:

Local $sString = "A very large chunk of data which we do not want to change"

Foo($sString)

Func Foo(Const ByRef $sText) ; The data is not copied, but also cannot be changed
	; Uncomment this line to see what happens when we try
	;$sText = "New value"
EndFunc   ;==>Foo

ByRef is a very powerful feature - but use it carefully, or you may find that you have changed a variable when you did not want to!

 

 

Edited December 23, 2019 by Musashi
insert a spoiler instead of a quote

[jchd]

Different syntaxes, different ways to waste cycles.  In order of increasing waste:

Global $hTimer, $bBoolean, $iMax = 5000000

$hTimer = TimerInit()
For $i = 1 To $iMax
    $bBoolean = 0
Next
ConsoleWrite("1. Time = " & TimerDiff($hTimer) & @CRLF)

$hTimer = TimerInit()
For $i = 1 To $iMax
    $bBoolean = False
Next
ConsoleWrite("2. Time = " & TimerDiff($hTimer) & @CRLF)

$hTimer = TimerInit()
For $i = 1 To $iMax
    $bBoolean = Not True
Next
ConsoleWrite("3. Time = " & TimerDiff($hTimer) & @CRLF)

$hTimer = TimerInit()
For $i = 1 To $iMax
    $bBoolean = Not(True)
Next
ConsoleWrite("4. Time = " & TimerDiff($hTimer) & @CRLF)

$hTimer = TimerInit()
For $i = 1 To $iMax
    $bBoolean = (1 = 0)
Next
ConsoleWrite("5. Time = " & TimerDiff($hTimer) & @CRLF)

AutoIt being an interpreter, it's quite logical that the more involved an expression is, the more work it requires at every invokation.

[argumentum]

I will add that readability is important.
For example: $MB_OKCANCEL (1) "OK and Cancel". Using 1 will be faster but less readable.
Nowadays, speed, flip-flops, however you look at it, is not as the 286 CPU era.
So these questions are good but do not sacrifice readability. Today's CPUs are quite fast  

Edited December 23, 2019 by argumentum

[TheAutomator]

49 minutes ago, jchd said:

Different syntaxes, different ways to waste cycles.  In order of increasing waste:

AutoIt being an interpreter, it's quite logical that the more involved an expression is, the more work it requires at every invokation.

hmm, strange..

1. Time = 4513.5517
2. Time = 4327.9589
3. Time = 5918.9678
4. Time = 7456.2174
5. Time = 8699.0866

test 2 has to first convert False to 0 according to a previous answer, but it takes less time?

Edited December 23, 2019 by TheAutomator

[TheAutomator]

7 hours ago, Musashi said:

Yes, but ByRef is not always required for arrays to avoid local copies ! This is described very comprehensively in Global,_Local,_Static_and_ByRef

Excerpt :

"It was mentioned earlier that when you pass variables to functions AutoIt makes local copies of these variables unless you declare that they are to be passed ByRef. In the special case of arrays, which are typically larger than a simple variable, AutoIt will only make a local copy if you change the array inside the function - merely accessing the array will use the original version. So passing the array ByRef is only advantageous if you intend to modify the array within the function - however, it does no harm to force the issue by using the keyword. "

How did i miss that? 😅
Thanks for the research!

[argumentum]

5 minutes ago, TheAutomator said:

but it takes less time?

...yeah, CPUs "cheat". If a calculation is been done more than a few times, is just replied without the calculation as the answer is known, so, follow the logic.  

[TheAutomator]

Just now, argumentum said:

...yeah, CPUs "cheat". If a calculation is been done more than a few times, is just replied without the calculation as the answer is known, so, follow the logic.  

nice, didn't know that,
but then it has to be the same for the other ones right? especially for the more easy one (1)

[jchd]

May 12-y old CPU(*) has different timings:

1. Time = 1346.66836591923
2. Time = 1419.11255965179
3. Time = 2037.54539549819
4. Time = 2592.13496621027
5. Time = 3133.78265580193

EDIT:
(*) Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
Please don't laugh!

Edited December 24, 2019 by jchd

[argumentum]

4 minutes ago, TheAutomator said:

then it has to be the same for the other ones right?

..is a muti-threaded OS. It all depends on what the OS gives as a time slice at the time. Hence, follow the logic. Can't go wrong there.

Edit: here are my results on a 8700k

1. Time = 632.262649350649
2. Time = 673.552346320346
3. Time = 1034.81406060606
4. Time = 1296.44993939394
5. Time = 1536.13021645022

 

Edited December 23, 2019 by argumentum

[jpm]

my I5-9300H @ 2.40GHz gives

1. Time = 702.5235
2. Time = 734.4926
3. Time = 1118.7819
4. Time = 1427.0543
5. Time = 1712.4993
 

[RTFC]

My new 256-cubit quantum computer gives Time = 0.0 for all five. What gives?

[argumentum]

...another thing to keep in mind is the time it takes for ...something else. A PC is as fast as the slowest thing.
Say that a disk write, in a slow disk, goes on while your loop is running, in the middle of it. The slice of time is gonna be longer, due to the process writing to disk.

So you may have a fast CPU but a slow HDD will be the bottle neck. Therefore, for some stuff I use a RAM disk. If you have a NVMe drive then ... 

Knowing software without understanding hardware will not do for a purist/perfectionist. I come from hardware then software came into existence. I guess that in a computer holy book would start with "In the beginning there was nothing, then a guy created a cable permitting electric potentials to flow.." 

It's handy to understand the hardware the software runs on. Otherwise is a mysterious enterprise.

[TheAutomator]

Argumentum,

I do my best to learn as much as possible and yes i still have much to learn, i'm sure you know not everyone on this forum started as a computer scientist 😉
Everything i know i had to teach myself, everything i code i want to program as smooth and efficient as possible.
Focusing on even the little details.. that's what i mean with perfectionism.

Sometimes the more you learn, the more you discover how little you know, so I'm grateful for all the tips and help 

Edited December 25, 2019 by TheAutomator

[water]

For the sake of completeness:
The wiki and the forum are a great source for good and efficient coding pactices

• Good coding  practice in the wiki
• Good coding practice discussion

[TheAutomator]

Yet another question:

Why do we use sleep(100) inside an "idle" loop?
Does it make the loop more CPU friendly, and how?
I would guess you're giving the CPU even more work like this? (read somewhere that sleep even does tiny sleeps with breaks to check for hotkey-presses)

example from helpfile in *GUI Reference - OnEvent Mode

While 1
    sleep(100)  ; Sleep to reduce CPU usage
Wend

ps: hopefully not breaking any rules by putting such a big time between new questions related to this topic..

[pixelsearch]

imho Sleep(10) is much better than Sleep(100) because it got exactly the same effect on CPU, i.e. it won't increase CPU usage at all and it won't increase its heat (task manager shows it on my antique PC)

Without Sleep(10) it's a total different story and CPU usage is increasing like crazy.

That's why, I guess, there's an implicit Sleep(10) in the instruction "Switch GUIGetMsg()" often found within the While...WEnd loop, which prevents CPU overheating.
 

[TheAutomator]

On 4/21/2022 at 4:16 AM, pixelsearch said:

imho Sleep(10) is much better than Sleep(100) because it got exactly the same effect on CPU, i.e. it won't increase CPU usage at all and it won't increase its heat (task manager shows it on my antique PC)

Without Sleep(10) it's a total different story and CPU usage is increasing like crazy.

That's why, I guess, there's an implicit Sleep(10) in the instruction "Switch GUIGetMsg()" often found within the While...WEnd loop, which prevents CPU overheating.
 

But, what makes it so that the CPU heats up?
What's the difference between "check while condition over and over again", or "check while condition, sleep millisecond, sleep millisecond, sleep millisecond, back to while condition..."?

[Earthshine]

checking over and over again without a pause is driving the cpu hard, that's why.