You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Besides not caching the downloaded JSON file on disk (see #5), an even bigger contributor to bad performance is the fact that we're running the code as a Swift script, i.e. the compiler will recompile it on every launch.
There are two components to this:
The pure compile time: a few hundred ms in my informal tests. Not catastrophically bad, but already noticeable.
Worse: every so often, launching the Swift compiler on macOS seems to take a really long time (easily 5–10 s in my experience) before it actually starts compiling/executing the script. I don't really understand why that is, but it's super annoying.
I see two options to improve the situation:
Ship the workflow with a precompiled binary executable. This is certainly possible, but macOS's Gatekeeper rules mean we'd have to properly sign and notarize the executable with a Developer ID certificate, otherwise the workflow will pop up an inscrutable error dialog.
As far as I can tell, this isn't super well supported by Apple. From what I read, we'd have to package the executable in an .app bundle or .pkg Installer package. It's probably doable, but sounds like a pain. Moreover, it could be weird if I used my Developer ID certificate to sign it given that I'm not the owner of this repository.
Ship the workflow without a precompiled excecutable, but add a separate Bash script se-lookup.sh and use that as the Workflow's entry point. On launch, the Bash script checks if a precompiled executable already exists and if it is newer than the Swift script. If yes, it launches the precompiled executable. Otherwise it compiles the Swift script first.
This means a slow launch time for the first launch after an update and fast launch times afterward. Plus, we don't have to deal with codesigning and notarization.
Unlike option (1), users of the workflow will still need a working Swift compiler (via Xcode or the Xcode command line tools). This isn't great, but I think it's acceptable.
I have prototyped option (2) and it seems to work fine. I'm inclined to go with it.
The text was updated successfully, but these errors were encountered:
ole
changed the title
Bad launch time due to recompiling the script on every launch
Long launch time due to recompiling the script on every launch
May 22, 2024
Besides not caching the downloaded JSON file on disk (see #5), an even bigger contributor to bad performance is the fact that we're running the code as a Swift script, i.e. the compiler will recompile it on every launch.
There are two components to this:
I see two options to improve the situation:
Ship the workflow with a precompiled binary executable. This is certainly possible, but macOS's Gatekeeper rules mean we'd have to properly sign and notarize the executable with a Developer ID certificate, otherwise the workflow will pop up an inscrutable error dialog.
As far as I can tell, this isn't super well supported by Apple. From what I read, we'd have to package the executable in an
.app
bundle or.pkg
Installer package. It's probably doable, but sounds like a pain. Moreover, it could be weird if I used my Developer ID certificate to sign it given that I'm not the owner of this repository.Ship the workflow without a precompiled excecutable, but add a separate Bash script
se-lookup.sh
and use that as the Workflow's entry point. On launch, the Bash script checks if a precompiled executable already exists and if it is newer than the Swift script. If yes, it launches the precompiled executable. Otherwise it compiles the Swift script first.This means a slow launch time for the first launch after an update and fast launch times afterward. Plus, we don't have to deal with codesigning and notarization.
Unlike option (1), users of the workflow will still need a working Swift compiler (via Xcode or the Xcode command line tools). This isn't great, but I think it's acceptable.
I have prototyped option (2) and it seems to work fine. I'm inclined to go with it.
The text was updated successfully, but these errors were encountered: