Beta version pre-v1.0.48: Up to 3x faster performance

Edit: v1.0.48 has been released, which includes all of the beta features below.

In this version almost all scripts should run faster -- especially scripts that make heavy use of expressions and integer math/comparisons, which may run up to 3x faster. To achieve the full benefit, a script should either avoid using SetFormat (especially "SetFormat Integer"), or use SetFormat's fast mode. This is because the old/slow mode causes some parts of binary-number caching to be disabled for the entire script.

This is a beta release because many low-level changes were made. Although extensively tested, I'd appreciate it if you could try it with your most demanding scripts to ensure a high-quality release.

Performance improvements:[*:33muxak6]Expressions and function calls are compiled more heavily, making them much faster (especially complex integer expressions, including those with commas).
[*:33muxak6]Literal integers in expressions and math/comparison commands are replaced with binary integers, which makes operations involving literal integers faster; e.g. X+5 and "if x > 5".
[*:33muxak6]Binary numbers are cached in variables to avoid conversions to/from strings. This makes numerical operations involving variables much faster. For example, passing an address to DllCall such as DllCall(VarContainingAddress) is up to 2x faster. However, taking the address of a variable (e.g. &var) permanently marks that variable as uncacheable because it allows the user to read/write its contents in unconventional ways.
[*:33muxak6]LOOPs, IFs, and ELSEs that have blocks (braces) are faster due to skipping the opening '{'. A side-effect is that the '{' is omitted from ListLines.
[*:33muxak6]The speed of thread creation has been improved, which should help rapid-fire threads in OnMessage(), RegisterCallback(), and GUI events.Changes that might affect existing scripts:[*:33muxak6]Floating point numbers stored in variables have higher precision; scripts that rely on tiny differences in precision might need updating. Alternatively, using "SetFormat Float" anywhere in the script (e.g. SetFormat, Float, 0.6) disables caching of floating point numbers, which should improve compatibility.
[*:33muxak6]When SetFormat, Integer, Hex is in effect, assigning a literal decimal integer to a variable also converts it to hex. Usually this is only a display issue.
[*:33muxak6]OnMessage(): For performance, the message number and HWND arrive as standard numbers rather than appearing unconditionally as hex. Usually this is only a display issue.
[*:33muxak6]LowLevel & dynamic code doesn't yet work with this version.
[*:33muxak6]In this version, scripts use slightly more memory (proportionate to the number of variables and expressions).Here is the new AutoHotkey.exe. If you wish, you can rename or move your original AutoHotkey.exe and put this one in its place: www.autohotkey.com/misc/AutoHotkey-Pre-1.0.48-new4.exe (238 KB)

For those who would like to compile scripts with this release, unzip the following file in your \Program Files\AutoHotkey\Compiler folder:
www.autohotkey.com/misc/AutoHotkey-Pre- ... N-new4.zip (240 KB)

Please let me know if you find any problems with it.

Soon I'll try to catch up on the bug reports and wish list forums. I'll also try to include some of Lexikos' changes.

Edit #1: Skan discovered that a command with zero parameters such as "Critical" can prevent a Loop, Exit, or ExitApp beneath it from receiving the correct first parameter. This has been fixed, and the link above now points to the corrected version.

Edit #2: Thanks to Icarus, the release has been fixed so that date-math with EnvSub (-=) works when the second parameter is a variable. The link above points to the corrected version.

Edit #3: LowLevel & dynamic code doesn't yet work with this beta version.

Edit #4: For those who would like to compile scripts with this release, there is now an SC/BIN file above for download.

Edit #5: The compiler/BIN file link above has been fixed on 12/30/2008 so that the /NoDecompile switch works.

Edit #6: Thanks to Lexikos, the release has been fixed so that bitwise operations involving floating point variables don't wrongly cache those variables as integers. The links above point to the corrected version.

Edit #7: Fixed the BIN/compiler ZIP file to contain the new version instead of the old one.

Edit #8: The compiler/BIN file link above has been fixed on 2/1/2009 so that SetFormat disables the caching of binary numbers in variables. This makes compiled scripts behave the same as non-compiled scripts.

Edit #9: There is a new beta version. It improves the speed of thread creation and fixes all the bugs in the Bug Reports forum that were readily fixable. The download links higher above point to the updated version.

Edit #10: I updated the files linked above without changing the filename/URL/version. There was a slight chance that a thread could become permanently uninterruptible if the PC was suspended/hibernated for more than 24 days (this is due to the 32-bit nature of GetTickCount()). This has been corrected.

Edit #11: On 2/19/2009 I updated the files linked above without changing the filename/URL/version. NumPut() has been improved to support UInt64 like DllCall() does. [thanks Sean]

Edit #12: Somewhere along the way, the SetFormat command was enhanced with a "fast mode" that avoids disabling the caching of binary numbers. For more details, see www.autohotkey.com/docs/commands/SetFormat.htm#Fast

Edit #13: On 2/20/2009 I updated the SC/bin file linked above without changing the filename/URL/version. The /NoDecompile option has been fixed (thanks pekkle).

Edit #14: 2/21/2009: I updated the files linked above without changing the filename/URL/version. Since backward compatibility is important, the following behaviors have been changed back to the way they were in non-beta versions:

func(0xFF)  ; The called function will now receive hexadecimal format rather than decimal.
x := 1, y := 0xFF  ; Assignments that occur inside pure expressions now retain hexadecimal formatting (isolated assignments like y:=0xFF always did this)

Since there is little performance impact to keep this backward compatibility, it seemed best to do so. It also makes hexadecimal behavior more consistent.

Sign In