Just a thought: I agree that running the scripts in a separate process is the best way. Could you set up a process or processes and re-use them? If they crash, then handle that however you do now, kill the process, and set up another one for reuse the next time.
I realize there's some questions involved in this, like how many processes, etc., and whatever else. It's just a thought.
This user, for one, is very grateful that reliability takes precedence, in KM's engineering, over hot-rod speed-tuning for the machine.
If an airport luggage delivery system is intermittently damaging and mis-delivering the luggage, tinkering around with running it faster will simply raise the temperature.
Our forests are green because Nature has learned that stability yields much better harvests than efficiency.
Why Are Plants Green? To Reduce the Noise in Photosynthesis. | Quanta Magazine
Donald Knuth 1974:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.
A fair point on not converting to AppleScript, except there is a case where you just might...
Probably trivial but there you might convert to a single AppleScript script where the key press is done in the script.
I'm sure there are less trivial cases.
Yes, it is not impossible that I could do that. Even a single relaunched process would probably be fine - executing AppleScripts would execute sequentially, but that is probably not a big problem (certainly not as big as locked the entire engine).
But it is a lot of work, so I'm not sure it will ever happen.
As I seem to be turning this thread into a general tuning one, does it make much difference what kind of machine Keyboard Maestro is running on? (Iām on a 2015 15ā MBP with 16GB memory and an SSD and I suspect things wouldnāt really go much faster on anything else.)
BTW I am generally happy with KM performance, particularly relative to the unreliable and slow - yet impatient - human alternative. 
When scripts and macros are embedded in a real working context, their
quality and value (reliability, ease of use and maintenance in that context, etc. etc.)
rarely turns out to have anything to do with performance.
Performance only looms large at times when we are playing around in our hobbyist or tinkering modes, and (lacking the specific challenges and demands of a richer context) reach for speed as a (doubtful, but familiar, easily grasped, and fairly easily measured) proxy for quality.
It's even atypical, in a desktop context, for time complexity ā let alone sub-second constant factors ā to matter very much.
Industrial volumes of data seldom cross most desktops, and on the rare occasions when they do, macros and user-scripts are probably not the thing to go for anyway.
I agree. The key word here is ātinkeringā: For me the edit/test/review cycle is key to my enjoyment of any environment. (And one where Iāve been less than ecstatic about with Drafts javascript actions.)
In Production itās fine - but then I havenāt really got into āViticci Modeā - with ultra long chains of actions.
I agree with you, and that's something I learned a while ago. I have to remind myself not to waste time on things that, in the long run, don't make a real difference. For me it comes back to the old days, when every clock tick and memory byte made much more of a difference.
While reading your post, it got me to thinking about something I've wondered about Apple UI automation (or whatever category this fits in) for quite a while:
When I do things (in JXA, if it matters) like get the contents of a list box in FCPX, it seems like it takes a LONG time, relatively speaking and depending on how many items are in the list box. I mean, it can take seconds (which may not seem like much, but it actually can be quite annoying).
It doesn't seem like it needs to take this long. Do you have any idea why this part of automation takes so long? I tend to get less annoyed when I understand what's happening behind the scenes.
I know this isn't a KM issue, by the way, and is probably off topic, but what the hey.
Probably because a GUI is expensive.
Not really. Keyboard Maestro Engine is designed to be extremely low resource usage, especially when idle.
An SSD will help if your Keyboard Maestro Macros.plist file is large (and will generally reduce a lot of cases where you can get sporadic/random lag on a Mac anyway).
A fast CPU will improve the performance of CPU intensive tasks like searching the screen or OCR, but in practice Keyboard Maestro has pretty good performance in these areas regardless of what Mac you are using.