AutoHotkey Community

With only the GetProcAddress optimization, a call to MulDiv takes 1.1µs on my system.

Changing the parameter types to str from int reduces the time by 0.2µs. Now no conversion is done - the function receives the address of the numeric literal, which is stored as a string. Up to this point, approximately 0.5µs (nearly 50%!) passes outside of DllCall.

If variable references or string literals are passed in place of numeric literals, the time spent outside DllCall is reduced by 0.1µs, with no visible affect on DllCall itself. Apparently numeric literals require more processing than variable references or string literals during expression evaluation.

It is not quite as clear-cut as "DllCall is slow." The efficiency of your code and the methods you use are more important. The first post in this topic contains a prime example: SetPixel is slow, regardless of which language you call it from.

Ordinarily, the solution would be to retrieve all of the image data at once, perform processing on it, then give the bitmap the updated image data. SKAN's example takes approximately 200ms on my system, which is considerably faster than Pil's original example. However, if I replace
with the equivalent machine code (compiled C++):
it takes 0, 16 or 30ms. It's too fast for A_TickCount to get an accurate reading! AutoHotkey is simply not suitable for this kind of processing.

It's been on my to-do list for a long time to change the script loading process to pre-tokenize and pre- infix-to-postfix all expressions (currently, only an expression's variables and functions are looked up in advance). In addition to catching more types of errors before the script begins running, this would also improve performance because those steps would be done only once (when the script starts) rather than each time the expression is encountered (such as in a loop). This would speed up all expressions and function calls (including built-in functions like DllCall).

The disadvantage is that it would use more memory because both the postfix and infix versions of each expression would be stored (for use by ListLines and error dialogs); it would also slow down launch time. But on balance, it seems worth it.

I've also added the following to the DllCall page in the documentation:

In v1.0.46.08+, even faster performance can be achieved by looking up the function's address beforehand. For example:
Thanks for the idea.

Really impressive.. On my machine SKAN´s code speeded up (using machine code in loop) from 320 to 31 msec.
Another nice example of what can be done with LowLevel.ahk

However there is no DllCall in the loop, that´s why SKAN placed it off topic.
Ofcourse efficiency of code is very important but my main use of DllCall is obtaining data on port with WinIO.dll (license CPL). Source c++ you can find at http://www.autohotkey.net/~pil/WinIo.rar I can´t find a work-around; only solution I found was writing a buffer(dll) in another language.
I tried Lazzlo´s sugestion translating the dll in machine code with the help of disasm.exe but had a lot of errors. I remember that Lazzlo himself had to deviate because of non-portable data reference when he tried to disassemble an existing dll.

That is exactly why it is a good example - if the script is too slow, there's a good chance DllCall overhead is not the issue.

OK I understand your point of view.
AHK´s help file says "DllCall returns the actual value returned by the function". Maybe the variable PortValIn can be treated different soon after call. Code below waits until a certain pattern appears on the parallel port (or loop finish) The io.dll (45kb) you can find at http://www.autohotkey.net/~pil/io.dll Time needed on my computer = 657 msec.

I don't see your point, or the relevance to this thread's topic...?

Tip: You don't need to use GetModuleHandle("io") as hModule already contains the value you need.

Tip: If you use the UChar return type, you won't need 0xFF &.

First of all thank you for the tips
Any way I only need "0xFF &" on older computers I think when the logical address of the computer CPU is 32 bits. There seems to be some garbage left on the varable which gives a wrong value.


So I am triing to improve my code/methods.
I need to monitor the parallel port for (very short) pulses so I have to put a DllCall in loop.
A Slow call will simply overlook short pulses, because/while processor is calculating. Of course the comparison "If PortValIn = 255" in loop will do the same, And it´s the only thing left to be improved.
Ahk`s help file says DllCall returns the actual value returned by the function.
So my question is; result is not necessariament an 64 byte long AHK variable? If no is there maybe som low level technique for comparision without the need of time taking conversion ?
Can you imagine some improvement?
The PortIn function is like the SetPixel function tem times slower then in other languages I tried.
Correction...after your GetProcAddress solution just 6,7 times slower!

"0xFF &" truncates to a value between 0 and 255 inclusive - i.e. an 8-bit value. Return values of 32-bit or less are passed via the eax register. If the function is defined as returning an unsigned 8-bit integer, the upper 24 bits of eax are undefined, and can have any value. Thus, if you leave the return type at the default "int" (32-bit signed integer), of course you'll get junk.

I would not recommend relying on the "junk" to be 0 on certain processors, as it is presumably undocumented and subject to change.
What makes you think AHK variable's are 64 bytes long? Even if 64 bytes are allocated for the variable, setting an integer between 0 and 255 will write only 2-5 bytes - "0" is 2 bytes including the null-terminator, while "0xff" is 5. More to the point, the speed of integer to string conversion is of more importance than memory usage.

If a variable is initially assigned a value of <4 bytes, it receives 3 bytes of "permanent" memory. If it is then assigned a value of between 4 and 7 bytes, it receives 7 bytes of "permanent" memory. If the variable is never assigned a value outside of the range 0-255 (or hexadecimal 0x0-0xff) and it is not a local variable of a recursive function, memory is allocated for it at most 2 times in the lifetime of the script.
(As with the return value of VarSetCapacity, the above excludes the extra byte allocated for the null-terminator.)
Only machine code functions.

In AHK doc´s you read: AutoHotkey has no explicitly defined variable types; all variables are stored as character strings.However, a variable containing only digits (with an optional decimal point) is automatically converted to a number when a math operation or comparison requires it. Conversely, the result of a math operation is converted back to a string when it needs to be stored in a variable

So the truth is that there is no initial string lenght for variables provided in AHK´s source.
Makes more sence, because I saw variables string lenght using hexediter searching in RAM just as in script. I just can´t imagine what PhiLho meant to say.

I feel it is bit misleading Mr.Chris, LoadLibrary() and GetModuleHandle() return the same value.



I think this would be better: But if the DLL isn't yet loaded, use LoadLibrary instead

It would be great if AHK has a built-in LoadDllFunction() - an example code:

Erhm, didn't read this thread, and I don't know if this has been mentioned. But anyways, as I've experienced AHK it's faster to define the type of the of the variable in between two "s...

e.g.

is slower than

The difference is that i put the value type between "s, so that it's treaded as a string...




with this i got 0.797 vs. the default code; 1.453... well it's atleast faster than not putting the value types between "s...

Ice_Tea, that is typically only true if Int, etc. are empty variables and you have not used #NoEnv, as referencing Int would then perform an environment variable lookup.

Oh, thanks for clearing that out to me .

Hoho..... HelpFile tells me, use #NoEnv to avoid checking empty variables to see if they are environment variables.
My example doesn´t use empty variables neither #NoEnv... But it should! Or quote the parameter types like Ice_Tea wrote.
Script speeds up on the PC I'm using at the moment from 3 to 1,32 seconds
Reading HelpFile further it says "It also improves DllCall's performance when unquoted parameter types are used (e.g. int vs. "int")"
So HelpFile should write: use #NoEnv to avoid checking empty variables to see if they are environment variables and to improve DllCall's performance when unquoted parameter types are used (e.g. int vs. "int") and to prevents script bugs caused by environment variables whose names unexpectedly match variables used by the script.
Further HelpFile is confusing about explaining use of quotes in DllCall, I can´t find something written like -using quotes gives better performance-
especialy in the part talking about performance, but in the examples it is used yes. Maybe here too should be mencioned the use of #NoEnv
Several times I tried use of quotes, but it didn´t make any difference.
Now I now; I used #NoEnv.