You feel there's a question in there somewhere ? I can see a request ...
My eyebrow was raised not at any 'question' but at a claim which I found a little silly and rude.
this really is unacceptable
I disagree with you that there is something 'speculative' , about the point that KM embeds scripts in a richer and more expensive architecture.
Consider the example below, which, whether run with the text script or script file option, returns a result to us. (Display in window, or various other options)
If we run the same from FastScripts, we see, and get, nothing at all. Gornisht.
The Fastscripts embedding is faster, but it's cheaper too.
The upcoming silence from me is an indication that I knew better than to try with you, and that I have no idea why I bothered. I have no one to blame but myself.
More interestingly, I think you will find that the KM vs FS difference is just an initial constant factor; the time from trigger to the onset of script evaluation.
There isn't, actually, any significant difference in the rate of script evaluation – scripts run at essentially the same speed in the two contexts, with the same amount of memory allocated, but FastScripts is noticeably quicker out of the starting gate.
FS achieves that quick response to the starter gun not only by carrying much less baggage, and discarding any outer layers like results collection, but also by pre-cacheing all of the scripts in its menu.
We're all aware that the first run of an .scpt file can involve a perceptible recompilation delay, at the start of a session, which disappears on repeated runs. FastScripts essentially does all that recompilation in advance. (Taking not inconsiderable time and spinning a widget for quite a while, on the first launch, if you have a lot of scripts and haven't made use of FastScripts for a while).
a 200ms-300ms initial delay of that kind, building up the execution environment, and possibly re-compiling the script, before it begins to run, will clearly be much more noticeable with a tiny BBEDit cursor move than with a report generation or some automatic diagramming on OmniGraffle.
In my view, the solution to that is probably to:
prefer FS to KM for flyweight editing moves that return no value,
and prefer KM to FS for everything else, especially if the script returns a value.
Not entirely sure that I understand the FastScripts side of the timing methodology used above (or how comparability was guaranteed, quite apart from the problem of interpreting a constant as a dramatic ratio) but,
if there is a solid pair of comparable tests, it would interesting to see whether the overhead of an Execute shell script is greater than the advantage of an FS pre-compilation cache
(I would guess that it is, especially with a tiny script, but I haven't designed an experiment)
The Set/Reset Action Delay action lets you set the various arbitrary delays used in Keyboard Maestro, either for this macro, or (semi)permanently for all macros.
You can set the following delays:
* Between Actions Delay (0.0 seconds)
* Copy/Paste Delay (0.2 seconds)
* Drag Delay (0.1 seconds + double click interval)
* Large Text Display (5 seconds)
* Simulate Normal Keystroke Delay (0.001 seconds)
* Simulate Command Keystroke Delay (0.15 seconds)
* Simulate Modifiers Delay (0.15 seconds)
* Simulate Dead Key Delay (0.03 seconds)
I've already answered this. There is nothing wrong with asking this question, but it has been asked before and the answer isn't likely to change.
As noted, your title is almost certainly inaccurate, there is no performance factor difference, the script will execute just as fast, there is almost certainly only an initial start lag as systems are setup.
FastScript has the scripts pre-compiled and pre-loaded and in its memory and executes the scripts within the FastScript process.
Long ago, Keyboard Maestro executed scripts within its process. However AppleScripts touch lots of systems, and some of them crash. And crashing the Keyboard Maestro Engine is unacceptable.
So Keyboard Maestro executes scripts outside of its process. This execution incurs a delay required to set up the new process and communicate between the processes. Some of this can be mitigated by pre-compiling your scripts, but some of it cannot.
In any performance trade, I will choose not crashing over more performance.
If I had a solution that would have better performance and not crash, I would implement it. I do periodically look at this issue and look for solutions, but I have never found one.
If the performance of any aspect of Keyboard Maestro is unacceptable to you, then don't use it.
Peter, regardless of the reasons, from the user's POV, this script does run 17.6X faster when run from FastScripts and from KM. I have provided you with the data and the script and macro, so you can test for yourself. In this particular script, it extra time that KM takes is very noticable when running this script in BBEdit.
While I agree that no one wants any software on their Mac to crash, the real world is that every software, including KM, crashes sometimes. I have observed this and it has been reported by others.
I'm not sure what that means. You make it sound as if you used the FastScript method of running AppleScripts KM would crash much more often. I don't believe this is the case. I and others have been running AppleScripts for years with FastScripts and rarely encounter a crash.
I understand that years ago you had a bad experience with AppleScript. Have you tested AppleScript lately using the FastScripts method? If so, could you please report the frequency of crashes you observe.
Finally, you have previously reported that KM uses AppleScript in many of its native Actions. If this be the case then speeding up the execution of AppleScript could have the effect of speeding of KM in many different areas, beyond the Execute AppleScript Action.
Hey Peter, I just had an idea that you might consider: Create a KM Beta that uses the FastScript method of executing AppleScripts, and let a few of us use it for a while. This could give you and us some real-world data on just how reliable AppleScript really is.
I for one would be willing to use this high-performance KM Beta on my production Mac.
Keyboard Maestro has almost no reported crashes currently. You would have to be fairly unlucky at this point - Keyboard Maestro’s crash rate is down to around one crash for every ten thousand user-days. While “every software, including KM, crashes sometimes” may be true, Keyboard Maestro itself does not crash in normal use for most users over their entire usage and I have no intention of changing that.
Yes, I do, and yes I believe it would, and no, I do not believe anything in this has changed.
In any event, executing scripts within the Keyboard Maestro Engine process is not plausible, since Keyboard Maestro performs multiple tasks simultaneously, which is not possible with AppleScript which is single threaded. As well as crashes, any script that takes any length of time would lock the Keyboard Maestro Engine up and stop it from performing any other tasks.
And of course, optimisation in context is not necessarily (perhaps not even often) the same as optimisation for run-time speed ...
Fusion of steps, more researched choice of actions, special measures with script files – all of these risk taking noticeably more human time and attention. The circumstances in which that would be a sensible price to pay for shaving off sub-second quantities of machine time could turn out to be rare ...
(I don't notice any general current of complaint about the run-time seconds used by KM. More a sense of gratitude that it brings more efficiency and focus to the human time)
However, in my tests this makes negligible difference.
The issue being described applies only to the Execute an AppleScript action (and to a degree, other Execute actions).
It does not apply to things like the Type a Keystroke action, so the last thing you want to do is convert them to AppleScript.
As with everything related to any form of optimisation - only optimise something that actively is causing you an issue. In the case described in this thread, presumably the 0.25s extra delay is an issue. In other cases (as part of a longer script for example), it would not be noticeable and indeed then, the script itself might then offer different opportunities for speeding it up - if the time taken was an issue.
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.
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.
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.
