Same here.
Scripts that call libraries using AppleScriptObjC no longer trigger error at launch.
Other scripts behaves normally.
So far…
MacOS 12.6 (21G115)
FastScripts 3.2.3b3 (1730)
Testing from the command line (with wrapper shell scripts), the results speak for themselves.
The test AppleScript I’m using is (called Test.scpt):
use framework "Foundation"
use framework "CoreWLAN"
current application's CWInterface's interface()'s ssid() as string
Testing with osascript.sh:
time osascript.sh Test.scpt
real 0m0.261s
user 0m0.181s
sys 0m0.053s
Testing with fastscripts.sh on FastScripts 3.2.3b2:
time fastscripts.sh Test.scpt
real 0m0.375s
user 0m0.022s
sys 0m0.024s
Testing with fastscripts.sh on FastScripts 3.2.3b3:
time fastscripts.sh Test.scpt
real 0m0.163s
user 0m0.018s
sys 0m0.021s
So, about a 200 ms speedup with the new beta (the remaining 163 ms is because of how I call the script, not due to FastScripts), making it effectively instantaneous, and way faster than osascript ever could be.
2 Likes
Thank you so much for going the extra mile to obtain those metrics! I hadn’t ever thought of the possibility of FastScripts as a faster alternative for invoking command line scripts. That’s pretty neat. I guess leveraging the pre-loaded script runner is the big win here. I’ll have to figure out how to promote this better after the update is public 
3 Likes
I wonder if it would be a worthwhile enhancement to consider providing a “fastscripts” command line utility that would essentially behave like “osascript” but with all the execution happening via FS instead.
3 Likes
That would be fantastic. I was planning on writing something similar for myself, but just haven’t gotten around to doing it yet.
I ran the above tests above using the little shell script I shared here, which is fairly slow because the boilerplate AppleScript code used to send the Apple Events to FastScripts is compiled on-the-fly.
On my own machine, I use a modified version of that shell script that runs the boilerplate AppleScript from a compiled .scpt file, which is much faster (but harder to explain on the forum). The benefit of this approach is a good balance of speed vs. complexity, since osascript still handles unpacking the result.
I was planning on tinkering around with writing a proper CLI in Swift for my own use, but it would be a lot more involved than doing the above. That said, an “official” solution would be awesome as everyone would have access & it would be a much more visible feature.
The other option, which may be easier to implement, would be to have FastScripts support “opening” files. That way, you would get free /usr/bin/open support, and could run scripts with:
open -a FastScripts /PATH/TO/FILE.scpt --args MyCoolArg1 MyCoolArg2
This would also allow scripts to be run from Finder by right-clicking, which would be useful.
The big downside to this approach would be that it may be trickier to return a script result… Script arguments could be handled with the --args option (and run flags with --env or parsing of --args).
Realistically, though, FastScripts can already do all of the above in a roundabout way, so whatever you decide is really just icing on the cake!
Thanks for the encouragement and for the thoughts. I suspect the way I would implement this would be to allow the FastScripts executable to be run from the command line, whether it’s running or not. If it was running then it would essentially act as a call-through to the running copy of the app to dispatch a script execution, and if it wasn’t running it would fire off a script runner just to do the one-time script run. So the “command line tool” would basically be an alias to the app’s executable.
2 Likes
Thanks again to folks here for reporting this. I finally got a chance to finish up the public update for FastScripts 3.2.3, which includes this fix: FastScripts 3.2.3: Better ASObjC Performance - Red Sweater Blog
3 Likes