How to optimize the speed of a script as much as possible.

[WAZAAAAA]

This code disables several ON-by-default "obscure" delays, unnecessary debug functions, gives an higher CPU priority to your scripts and contains an high precision Sleep function.
Please note that inside the spoiler of note #8 you can find a good benchmark script to test the speed of your scripts.


Generic optimizations
Just copy this at the beginning of any AHK script to make use of the performance optimizations:

Code: Select all

#NoEnv
#MaxHotkeysPerInterval 99000000
#HotkeyInterval 99000000
#KeyHistory 0
ListLines Off
Process, Priority, , A
SetBatchLines, -1
SetKeyDelay, -1, -1
SetMouseDelay, -1
SetDefaultMouseSpeed, 0
SetWinDelay, -1
SetControlDelay, -1
SendMode Input

;YOUR SCRIPT GOES HERE, but first some recommendations
;the Unicode x64bit version is the fastest AHK installation
;use PixelSearch without Fast if you're searching for a single pixel of a single shade
DllCall("Sleep",UInt,16.67) ;I just used the precise sleep function to wait exactly 16,67 milliseconds!

^Notes
1. #NoEnv is recommended for all scripts, it disables environment variables.

Spoiler

More info: https://autohotkey.com/docs/commands/_NoEnv.htm

2. The default #MaxHotkeysPerInterval along with #HotkeyInterval will stop your script by showing message boxes if you have some kind of rapid autofire loop in it. Just put some insane unreachable high number to ignore this limit.

Spoiler

More info: https://autohotkey.com/docs/commands/_M ... terval.htm
https://autohotkey.com/docs/commands/_H ... terval.htm

3. ListLines and #KeyHistory are functions used to "log your keys". Disable them as they're only useful for debugging purposes.

Spoiler

More info: https://autohotkey.com/docs/commands/ListLines.htm
https://autohotkey.com/docs/commands/KeyHistory.htm

4. Setting an higher priority to a Windows program is supposed to improve its performance. Use AboveNormal/A. If you feel like it's making things worse, comment or remove this line.

Spoiler

In my experience and according to user Ffkwa, using "Realtime" is actually counterproductive (Windows' Task Manager warns you about this instability as well, same for AHK's documentation)
https://autohotkey.com/docs/commands/Process.htm

5. The default SetBatchLines value makes your script sleep 10 milliseconds every line. Make it -1 to not sleep (but remember to include at least one Sleep in your loops, if any!)

Spoiler

More info: https://autohotkey.com/docs/commands/SetBatchLines.htm

6. Even though SendInput ignores SetKeyDelay, SetMouseDelay and SetDefaultMouseSpeed, having these delays at -1 improves SendEvent's speed just in case SendInput is not available and falls back to SendEvent.

Spoiler

https://autohotkey.com/docs/commands/Se ... putUnavail

7. SetWinDelay and SetControlDelay may affect performance depending on the script.

Spoiler

More info: https://autohotkey.com/docs/misc/Performance.htm

8. SendInput is the fastest send method. SendEvent (the default one) is 2nd place, SendPlay a far 3rd place (it's the most compatible one though). SendInput does not obey to SetKeyDelay, SetMouseDelay, SetDefaultMouseSpeed; there is no delay between keystrokes in that mode.

Spoiler

You can test this yourself by benchmarking the 3 methods. Here's a script you can use to do it (read the commented lines for instructions):

Code: Select all

#NoEnv
#SingleInstance Force
#MaxHotkeysPerInterval 99000000
#HotkeyInterval 99000000
#KeyHistory 0
ListLines Off
Process, Priority, , A
SetBatchLines, -1
SetKeyDelay, -1, -1
SetMouseDelay, -1
SetDefaultMouseSpeed, 0
SetWinDelay, -1
SetControlDelay, -1
SendMode Input

DllCall("QueryPerformanceFrequency", "Int64*", Frequency)
StartTime := A_TickCount
DllCall("QueryPerformanceCounter", "Int64*", CounterBefore)
Loop 10000
{
	SendEvent {Pause} ;run the script 3 times by switching SendEvent to SendInput and SendPlay to benchmark the 3 different Send methods.
	;to benchmark other kinds of scripts, when the script ends with an If variable, you can end the Loop with Continue. When Continue is unusable, use Sleep -1 instead.
}
DllCall("QueryPerformanceCounter", "Int64*", CounterAfter)
ElapsedTime := A_TickCount - StartTime
MsgBox % "TickCount:`n" ElapsedTime " ms`n`n" "QueryPerformanceCounter:`n" . (CounterAfter - CounterBefore)*1000/Frequency . " ms"

9. If you're not using any SetTimer, the high precision sleep function is useful when you need millisecond reliability in your scripts. It may be problematic when used with SetTimer in some situations because this sleep method pauses the entire script. To make use of it, here's an example that waits 16,67 milliseconds:
DllCall("Sleep",UInt,16.67)

Spoiler

You can read more about this and alternative sleep functions at RHCP's excellent thread (there are more Sleep methods there, like one that doesn't affect SetTimer's but uses high CPU) http://www.autohotkey.com/board/topic/9 ... -function/
You can read more about the inaccuracy of the default Sleep here: https://autohotkey.com/docs/commands/Sleep.htm and eventually try to benchmark the various Sleeps with the benchmark code at point 8.
If you're familiar with RegEx (smart find&replace), you could replace in bulk your default sleeps with high precision ones, like this:
SEARCH:Sleep, (\d+)
REPLACE:DllCall\("Sleep","UInt",\1\)

10. When using PixelSearch to scan a single pixel of a single color variation, don't use the Fast parameter. According to my benchmarks, regular PixelSearch is faster than PixelSearch Fast in that case.

Spoiler

More information with benchmarks: https://autohotkey.com/boards/viewtopic.php?f=5&t=5920

11. According to the documentation (this text is found in the setup file), the Unicode x64bit version of AHK is faster, use it when available.

Spoiler

Defining variables (benchmark)
explained by jNizM

Speed Test (Benchmark): Define Variables

explained by dd900

Performance: In v1.0.48+, the comma operator is usually faster than writing separate expressions, especially when assigning one variable to another (e.g. x:=y, a:=b). Performance continues to improve as more and more expressions are combined into a single expression; for example, it may be 35% faster to combine five or ten simple expressions into a single expression.

As suggested by the documentation I have changed

Code: Select all

a := 1
b := 2
c := 3
d := Function( param )
e := AnotherFunc( d )
return

to

Code: Select all

a := 1
, b := 2
, c := 3
, d := Function( param )
, e := AnotherFunc( d )
return

My project is rather large and doing this over my entire script has caused a noticeable increase in speed.

VarSetCapacity optimization

in my experience (and according to the documentation), using VarSetCapacity() improves performance when building a string by means of gradual concatenation. From the documentation:

In addition to its uses described at DllCall, this function can also be used to enhance performance when building a string by means of gradual concatenation. This is because multiple automatic resizings can be avoided when you have some idea of what the string's final length will be.

From the example in the documentation (although not a working example...):

Code: Select all

; Optimize by ensuring MyVar has plenty of space to work with.
VarSetCapacity(MyVar, 10240000)  ; ~10 MB
Loop
{
    ...
    MyVar = %MyVar%%StringToConcatenate%
    ...
}

Speedup DllCall

Speedup DllCall's (excluded: "User32.dll", "Kernel32.dll", "ComCtl32.dll" & "Gdi32.dll")

Found in old Forum (Code by Bentschi)

Functions: LoadLibrary() & FreeLibrary()

Code: Select all

LoadLibrary(filename)
{
    static ref := {}
    if (!(ptr := p := DllCall("LoadLibrary", "str", filename, "ptr")))
        return 0
    ref[ptr,"count"] := (ref[ptr]) ? ref[ptr,"count"]+1 : 1
    p += NumGet(p+0, 0x3c, "int")+24
    o := {_ptr:ptr, __delete:func("FreeLibrary"), _ref:ref[ptr]}
    if (NumGet(p+0, (A_PtrSize=4) ? 92 : 108, "uint")<1 || (ts := NumGet(p+0, (A_PtrSize=4) ? 96 : 112, "uint")+ptr)=ptr || (te := NumGet(p+0, (A_PtrSize=4) ? 100 : 116, "uint")+ts)=ts)
        return o
    n := ptr+NumGet(ts+0, 32, "uint")
    loop % NumGet(ts+0, 24, "uint")
    {
        if (p := NumGet(n+0, (A_Index-1)*4, "uint"))
        {
            o[f := StrGet(ptr+p, "cp0")] := DllCall("GetProcAddress", "ptr", ptr, "astr", f, "ptr")
            if (Substr(f, 0)==((A_IsUnicode) ? "W" : "A"))
                o[Substr(f, 1, -1)] := o[f]
        }
    }
    return o
}

FreeLibrary(lib)
{
    if (lib._ref.count>=1)
        lib._ref.count -= 1
    if (lib._ref.count<1)
        DllCall("FreeLibrary", "ptr", lib._ptr)
}

Test Script:

Code: Select all

loops := 1000000
SetBatchLines, -1
global gdiplus := LoadLibrary("gdiplus")
VarSetCapacity(bin, 20, 0)
NumPut(1, bin, 0, "int")
DllCall(gdiplus.GdiplusStartup, "ptr*", token, "ptr", &bin, "ptr", 0)
DllCall(gdiplus.GdipCreateBitmapFromScan0, "int", 1, "int", 1, "int", 0, "int", 0x26200A, "ptr", 0, "ptr*", pBitmap)

start := A_TickCount
loop % loops
    DllCall("gdiplus\GdipBitmapGetPixel", "ptr", pBitmap, "int", 1, "int", 1, "uint*", col)
timeA := A_TickCount-start

start := A_TickCount
loop % loops
    DllCall(gdiplus.GdipBitmapGetPixel, "ptr", pBitmap, "int", 1, "int", 1, "uint*", col)
timeB := A_TickCount-start

DllCall(gdiplus.DisposeImage, "ptr", pBitmap)
DllCall(gdiplus.Cleanup, "ptr", token)
MsgBox % "Normal:`n" timeA "`n`nWith LoadLibrary:`n" timeB "`n`n" timeA/timeB

Result:

Code: Select all

---------------------------
LoadLibrary.ahk
---------------------------
Normal:
1828

With LoadLibrary:
781

2.340589
---------------------------
OK   
---------------------------

Export Table:

Code: Select all

global gdiplus := LoadLibrary("gdiplus")
for name, proc in gdiplus
{
    if (name!="_ptr" && name!="_ref" && name!="__delete")
        MsgBox % name
}

Ternary vs if/else

Code: Select all

Ternarry:        2.828439
if/else:         3.931492

Code:

Spoiler

Code: Select all

SetBatchLines -1

global lcnt := 10000000
global VarA := "Hello"
global VarT_1 := VarT_2 := False
global VarI_1 := VarI_2 := False

; ===============================================================================================================================

QPC(1)

loop % lcnt
{
    VarT_1 := (VarA = "Hello") ? True : False
    VarT_2 := (VarA = "World") ? True : False
}
test1 := QPC(0)

; ===================================================================================

QPC(1)

loop % lcnt
{
    if (VarA = "Hello")
        VarI_1 := True
    else
        VarI_1 := False

    if (VarA = "World")
        VarI_2 := True
    else
        VarI_2 := False
}
test2 := QPC(0)

; ===================================================================================

MsgBox % test1 "`n" test2
ExitApp

; ===============================================================================================================================

QPC(R := 0)
{
    static P := 0, F := 0, Q := DllCall("QueryPerformanceFrequency", "Int64P", F)
    return !DllCall("QueryPerformanceCounter", "Int64P", Q) + (R ? (P := Q) / F : (Q - P) / F) 
}

Don't spread math/variables over multiple lines

Avoid spreading math over multiple lines and using variable for intermediate results if they are only used once.
As much as possible condense math into one line and only use variables for storing math results if you need the results being used multiple times later.

remember that:
1x calc < 1x calc + 1x memory read < 2x calc

Code: Select all

#NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.

#Singleinstance force
SetBatchlines, -1
ListLines Off
#KeyHistory 0

var_Input1:=123
var_Input2:=456


start:=A_tickcount
Loop 99999999
	{
	X:= (2 * var_Input1 ) -1
	Y:= (3 / var_Input2 ) +7
	Z:= X / Y
	}
Results1:=A_tickcount - start


start:=A_tickcount
Loop 99999999
	{
	Z:= ((2 * var_Input1 ) -1) / ((3 / var_Input2 ) +7)
	}
Results2:= A_tickcount - start


msgbox %Results1% - %Results2%

The second condensed method is slightly more than 50% faster

Gosub VS functions

This is probably way down into miniscule area but
Using Gosub seems to be 25% faster than using a function.

SetProcessWorkingSetSize VS EmptyWorkingSet

Another miniscule speed tip

Replacing

Code: Select all

    DllCall("SetProcessWorkingSetSize", Int,-1, Int,-1, Int,-1 )

with

Code: Select all

    return, dllcall("psapi.dll\EmptyWorkingSet", "UInt", -1)

You get around a 27% speedup on that emptymem call

Checking Boolean values with if

a few tips for IF checking of Boolean values
Tested on a Core2Quad Q6600 system.


if VariableName
Seems to be the fastest way to check if a variable is True


if VariableName = 0
Is the fastest way to check if a variable is false however it does not take into account of the variable is not set, aka empty. The IF commands does not get activaged if the variable is not set/empty

if VariableName <> 1
is almost as fast and an empty variable is considere false ( aka the IF settings get activated) just like if it contained a 0

if Not VariableName
Seems to be slower than both of the two above

Previous inputs from the members of the archived forum are located here: https://autohotkey.com/board/topic/9445 ... -possible/
Feel free to add any possible contribution and I will include them. GOTTA GO FAST.

[WAZAAAAA]

Oh my, maybe I should've posted this in the Tutorials section. Moderators what do you think?

[joedf]

I think it's fine here.

[Skrell]

I REALLY like where this thread is heading! I've always wanted to know more about speed optimizations in AHK! Please post more benchmarks/comparisons if possible on ANY functions in AHK that essentially do the same thing. For instance, i use a LOT of settimer commands in my code and would love to know if you have any thoughts on it.
Also can you please comment more on these values (what the trade off is in using them):

SetTitleMatchMode 2
SetTitleMatchMode fast
SetBatchLines, -1
SetKeyDelay, -1, -1, -1
SetMouseDelay, -1
SetWinDelay, -1
SetControlDelay, -1
SetDefaultMouseSpeed, 0

[jNizM]

Speed Test (Benchmark): Define Variables

[Skrell]

Speed Test (Benchmark): Define Variables

Would you mind explaining what this is doing?
QPC(R := 0)
{
static P := 0, F := 0, Q := DllCall("QueryPerformanceFrequency", "Int64P", F)
return ! DllCall("QueryPerformanceCounter", "Int64P", Q) + (R ? (P := Q) / F : (Q - P) / F)
}

I dont understand how this function manages to measure the time it takes to assign variables by using QPC(0) and QPC(1)

[jNizM]

Code: Select all

_QPC(Reset := 0) ; By SKAN,  http://goo.gl/nf7O4G,  CD:01/Sep/2014 | MD:02/Sep/2014
{
	static PrvQPC := 0, FRQ := 0, QPC := 0

	if !(FRQ)
		DllCall("kernel32.dll\QueryPerformanceFrequency", "Int64P", FRQ)

	DllCall("kernel32.dll\QueryPerformanceCounter", "Int64P", QPC)

	if (Reset)
	{
		PrvQPC := QPC
		return QPC / FRQ
	}
	else
	{
		return (QPC - PrvQPC) / FRQ
	}
}

[Ffkwa]

Ok, I can't edit. So here are my findings:

1. Realtime priority is bad news almost always. Don't do that. It almost never works, even if your script is written correctly. If your script is written incorrectly, then you can cause your entire system to hang.
2. High priority/above normal priority sometimes work. You can try them, but they are a very big potential source of problems. Disable them if something is going wrong.
3. Spintest sleep (sleepz) doesn't work when scripting for programs that require CPU time to process. For example, if you're trying to script for a game, then your script will hog all the processor time and the game will lag.
4. Batchlines 0 forces your script to consume CPU time even when you sleep. That absolutely kills performance in the rest of the system. Don't do it.
5. Setting batchlines to normal right before Sleep seems to not change anything at all. It still consumes huge CPU timeslices.
6. WAZAA is absolutely correct about the speed of SendMode Input and SendMode Event, but the difference is tiny compared to the variability of Sleep. I suspect that Event may still be less reliable, but I am not sure and don't have meaningful tests for reliability.

[lexikos]

Batchlines 0 forces your script to consume CPU time even when you sleep.

No. SetBatchLines does not affect Sleep at all. It determines how often the program "rests" (sleeps for 10ms) in between execution of lines of script. If the script is not executing code (i.e. it is idle, waiting or sleeping), the setting has no effect.

That absolutely kills performance in the rest of the system. Don't do it.

On my 5yo system, a single script utilizing maximum CPU time does not noticeably affect performance at all, let alone "kill" it. Most systems have at least a dual-core CPU, and a script is only capable of tying up one core.

It still consumes huge CPU timeslices.

There's something wrong with your script, or your system. While sleeping, the program checks its message queue and then yields its CPU time slice, and repeats. There is generally no measurable CPU usage unless there is a flood of messages to process (having been sent to the script's own window(s)).

---

Edit:
To be clear, I am not condoning the OP's suggestions. For instance, these will not make the script run faster, and might even be undesirable:

Code: Select all

#MaxThreads 255
#MaxMem 4095
#MaxThreadsBuffer On
#MaxHotkeysPerInterval 99000000
#HotkeyInterval 99000000

Most scripts will never need more than the default #MaxThreads (10). That means something like a hotkey starts, then is interrupted by another, and another, etc. so that there are 10 running that have not yet completed. If that happens and you hit the default limit, there's probably a problem with the design of your script.

#MaxMem: "The purpose of limiting each variable's capacity is to prevent a buggy script from consuming all available system memory. Raising or lowering the limit does not affect the performance of a script"

The default settings for #MaxHotkeysPerInterval and #HotkeyInterval enable a safe-guard against accidentally causing infinite loops with hotkeys that send keys which can trigger hotkeys. Using the settings shown above would disable this safe-guard. (However, disabling it is sometimes useful - for example, some Logitech mice have a free-spinning mouse wheel, which can easily exceed the default hotkey limit for a WheelUp/WheelDown hotkey.)

[Ffkwa]

I'm glad I posted. Thanks for the informative response!

Batchlines 0 forces your script to consume CPU time even when you sleep.

No. SetBatchLines does not affect Sleep at all. It determines how often the program "rests" (sleeps for 10ms) in between execution of lines of script. If the script is not executing code (i.e. it is idle, waiting or sleeping), the setting has no effect.

That absolutely kills performance in the rest of the system. Don't do it.

On my 5yo system, a single script utilizing maximum CPU time does not noticeably affect performance at all, let alone "kill" it. Most systems have at least a dual-core CPU, and a script is only capable of tying up one core.

This was my mistake. This is affected by my test setup I forgot to mention. I'm on VMWare, with only one core. So anything that behaves badly causes system-wide lockdown for me.

It still consumes huge CPU timeslices.

There's something wrong with your script, or your system. While sleeping, the program checks its message queue and then yields its CPU time slice, and repeats. There is generally no measurable CPU usage unless there is a flood of messages to process (having been sent to the script's own window(s)).

You are right, my testing script had a mistake. I was testing a special sleep() function which used normal Sleep for a long duration, then a spintest Sleepz() to have fine resolution at the end. But my function calculated used "Sleep % %period% - 15.7" which meant I was just testing the high resolution timer.

[Ffkwa]

The OP and I are actually both scripting for the same game. The context is that frames take ~16ms - 22ms, and it's important that sent keys resolve on discrete frames.

I'm thinking about letting my script force Windows's built in tick from 15.6 ms to maybe 5 ms. The downside would be power consumption, and probably excessive context switches, but maybe it will improve Sleep consistency. I'm also kind of wondering how VMWare will handle this tick resolution, given that I've disabled its "backdoor" port that lets it communicate with the host system. Would my host system get the changed tick as well? And if my script crashes and forgets to reset the timer, will my system be stuck at a 5ms tick until reset?

[Guest]

Doing some reading, I found that the timer tick rate will reset when your process terminates, which is good.

[KuroiLight]

SetBatchLines, -1 should be enough, as long as you sleep somewhere in your loops.

That absolutely kills performance in the rest of the system. Don't do it.

On my 5yo system, a single script utilizing maximum CPU time does not noticeably affect performance at all, let alone "kill" it. Most systems have at least a dual-core CPU, and a script is only capable of tying up one core.

Whether or not it kills performance really depends on the system and script, but I'd still recommend against anything non-critical running as real-time (possibly starving the process your scripting for); if you need that much of the cpus time for a script it might be better to revisit the code to see if it can be reduced.

edit*:

The default settings for #MaxHotkeysPerInterval and #HotkeyInterval enable a safe-guard against accidentally causing infinite loops with hotkeys that send keys which can trigger hotkeys. Using the settings shown above would disable this safe-guard. (However, disabling it is sometimes useful - for example, some Logitech mice have a free-spinning mouse wheel, which can easily exceed the default hotkey limit for a WheelUp/WheelDown hotkey.)

It would be nice to be able to turn of the popup you get when these limits are exceeded, and just halt the script for a time.


just my 2cents.

[lexikos]

It would be nice to be able to turn of the popup you get when these limits are exceeded, and just halt the script for a time.

On the surface that seems like a good idea, but the point of the limit and the popup is that hitting the limit often indicates an error in the script which should be fixed, and the popup directs users to the solution. Suppressing the popup and instead blocking the hotkey for a time would likely result in the script being left as is, not behaving the way the user expects - either because they get an occasional flood of hotkeys (from a send-hotkey loop) that wasn't intentional, or because their rapid-fire hotkey doesn't work consistently.

If you're specifically opting to suppress the popup but keeping the limit, that basically means you expect the hotkey to fire very rapidly sometimes, but still want to limit the number of activations per interval. I don't think that would be a common case.

[KuroiLight]

It would be nice to be able to turn of the popup you get when these limits are exceeded, and just halt the script for a time.

On the surface that seems like a good idea, but the point of the limit and the popup is that hitting the limit often indicates an error in the script which should be fixed, and the popup directs users to the solution. Suppressing the popup and instead blocking the hotkey for a time would likely result in the script being left as is, not behaving the way the user expects - either because they get an occasional flood of hotkeys (from a send-hotkey loop) that wasn't intentional, or because their rapid-fire hotkey doesn't work consistently.

If you're specifically opting to suppress the popup but keeping the limit, that basically means you expect the hotkey to fire very rapidly sometimes, but still want to limit the number of activations per interval. I don't think that would be a common case.

I agree, I've only encountered this once so far with my scroll script, since someones mouse wheel could potentially send 10s or 100s of events at a time. I think it would be better if after a set limit of it would end the thread, e.g.

Code: Select all

#MaxThreadsPerHotkey, 1
#InterruptMaxThread, true

allowing only 1 thread for the hotkey to exist at a time and interrupting it if its too slow, but not blocking it. ofc this has problems too.

sorry to derail the thread op, i'm done.

[lexikos]

I don't understand your suggestion

One of three things can happen if the hotkey is activated when it already has a thread running:

• The new thread interrupts the older ones, which can be resumed some time after the new thread finishes.
• The hotkey is running the maximum number of threads, so the event is ignored/discarded (#MaxThreadsBuffer Off).
• The hotkey is running the maximum number of threads, so the event is buffered/postponed (#MaxThreadsBuffer On).

Maybe what you're saying is that one of the hotkey's previous threads should be terminated before starting the new thread, but that simply can't be done with the current thread design. It also has nothing to do with the problem #MaxHotkeysPerInterval is meant to detect: rapidly repeated (not simultaneous) activations of a hotkey.

[KuroiLight]

hotkey's previous threads should be terminated before starting the new thread,

yeah, this is what I meant, no big deal though, I can work around it.

[Sam_]

So, taking the above into account, following the recommendations in the documentation (generally a wise move), and rearranging a bit, we now have:

Code: Select all

#NoEnv
Process, Priority, , H
SetBatchLines, -1
ListLines Off
#KeyHistory 0
SendMode Input
SetTitleMatchMode 2
SetTitleMatchMode Fast
SetKeyDelay, -1, -1, Play
SetMouseDelay, -1
SetWinDelay, 0		; Changed to 0 upon recommendation of documentation
SetControlDelay, 0	; Changed to 0 upon recommendation of documentation
SetDefaultMouseSpeed, 0

; YOUR_SCRIPT_HERE

Edited SetKeyDelay. See next post.

[lexikos]

SetKeyDelay, -1, -1, -1

The third parameter should be the word "Play" or nothing at all. -1 has no meaning.

[Sam_]

SetKeyDelay, -1, -1, -1

The third parameter should be the word "Play" or nothing at all. -1 has no meaning.

Thanks for the catch! I updated my last post.