I’ve never used NSAppleScript to compile and invoke a complied AppleScript so I have a question regarding the performance benefits, if any, of this feature.
Will invoking a compiled AppleScript from my own macOS app (using NSAppleScript), that only targets my own app’s scriptable commands, avoid interprocess communication latency that would exist if I invoked that same script from say, Script Editor?
I realise that there is the Apple Event Manager involved in this mechanism, but I’m not sure where latency issues typically arise, and whether there is anything to be gained from providing an in-app automation interface in addition to the typical stand-alone script convention.
If I’m wanting to provide automation for over-the-wire instructions (which are no more than 3 bytes per instruction) that can typically happen at a speed of approximately 1,000 instructions/second, I realise that invoking each command from a stand-alone script might reduce/cripple that throughput quite considerably. The challenge is to provide some sort of programmable automation without constraining the throughput.
Scripting Bridge is fast, but it’s also not accessible to the end users of my app. The users of my app will only be expected to know AppleScript to write automation routines, so Scripting Bridge is out of the question.
to provide automation for over-the-wire instructions (which are no more than 3 bytes per instruction) that can typically happen at a speed of approximately 1,000 instructions/second
To make a decision for this use-case, instrumenting your macOS code to provide timing data might be best. You could roll your own time logging or, if using XCode for your Mac app, use Instruments.
Real-world performance in automation can be affected by dozens, if not hundreds, of factors, so collecting timing data will both answer the implementation questions and be invaluable for on-going support of the application.
To call handlers directly in a compiled script I recommend to send AppleEvents with execute(withAppleEvent: of NSUserAppleScriptTask, which is pretty fast and even allowed in a sandboxed app.
In case your app is written in Swift you can take advantage of async/await / Swift Concurrency to execute the calls in sequence without running into data races.
Thanks for the advice @ronzo99. You’ve actually reminded me that I can probably get a decent look at Apple Event Manager / system latency using Instruments.
