I have some routines that run frequently to tell me what's going on, confirm what I'm about to do, etc. and some of them rely heavily on AppleScript to get info about files, etc. I've already learned that it all runs faster if I do several things at once in one AppleScript script rather than having modular scripts called by individual KBM actions and macros.
But there are some places where it takes two to three seconds to report to me when I'd prefer it to be under a second, that it's part of my flow and I'm not waiting for the system to catch up with me. These ran pretty fast when I was doing only a single task with AppleScript, but conditionals for annoying edge cases have made the AppleScript more complex and created the experience of waiting.
If I compiled that AS script as an app with Script Editor and then called that from KBM, would that run faster?
I love being able to edit a AS script in the KBM Editor and have the results immediately available, but I'd give that up in the cases where the respose time has just gotten too slow for comfort, so I'd save the external compilation for scripts that have settled down in their development.
I can try it myself, of course, but it would divert me for a couple of days at least, because I only have an hour or so a day for KBM. So I'm asking for any voices of experience to let me know what they've found out before start down this sidetrack.
Does external compilation of AppleScripts work straightforwardly and does it speed things up?
I feel like @ccstone has said several times that external AppleScript triggered via FastScripts was his go-to method when speed was most important, so I assume so? But I don't have scripts large enough to feel the delay I don't think.
Edit: this must be what is on my mind from browsing recently:
PS: I was able to find this quickly thanks to HistoryHound, something I began using earlier this year. It's been very helpful!
I got chance to do some testing of an AS script that does a half dozen things before returning a value, where KBM then displays the value. I had three versions to choose between by enabling/disabling actions. One was the script in KBM, second was the AS compiled as .scpt, and third was the script compiled as .app.
With this relatively lightweight AppleScript, I noticed little difference in the two compiled versions and a slight improvement in those compared to the KBM script. Subjectively, it seemed like it took about 1.5 to 2 seconds for the displayed value to appear in the KBM version and about 1 to 1.5 seconds with the compiled versions.
It occurred to me that capturing video of the display would allow me to count frames between the triggering event and the displayed result. But I'm not that ambitious tonight.
Thanks again for the Replace tool. I look forward to trying it.
I looked up FastScripts and found this information from the developer/publisher about Version 3:
FastScripts is free to use with premium features disabled. The number and depth of premium features may grow over time, but as of FastScripts 3’s debut, these are the features that are considered premium, and a description of how they behave when used without a paid license:
Keyboard shortcuts. When you invoke a script by keyboard shortcut, you will be reminded of the limitation in the free version. After dismissing the reminder, the script will proceed to run.
Built-in scripting additions. Features such as FastScripts’s “display message” command for presenting “HUD-style” messages, the new “open web page” scripting command, and other added utilities, are all premium features. When you use one of these features, they will still work, but a dialog will appear first to remind you that they are not included in the free version.
That’s it! All of the other great features of FastScripts are completely free to use, so if you don’t miss any of the premium features, feel free to use and enjoy the app to your heart’s content!
Don't do that, just use a timer call before and after the event, and it'll tell you exactly how long it took. At it's most simplistic, put the current time into a variable before you run the AppleScript, then put the time into a different variable when it's done. Calc the difference and display.
I took this simplicity to advanced levels of complexity in MultiTimer, but you can use it in simple mode, too—just call it with startquiet and then again with end.
Because I'm trying to tune an action that takes two seconds or less, even an improvement of 25% can be difficult to notice exactly, it's a much more subjective thing of having to wait a beat vs. having to wait a longer beat.
