alfred-swift-evolution icon indicating copy to clipboard operation
alfred-swift-evolution copied to clipboard

Long launch time due to recompiling the script on every launch

Open ole opened this issue 1 year ago • 0 comments

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:

  1. 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.

  2. 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.

ole avatar May 22 '24 14:05 ole