The frozen binary takes ~19 s to run ANY command, including --version — PyInstaller onefile re-extracts 14 MB on every invocation

[hkngln]

Measured

Installed v0.5.0-rc3 via install.sh on macOS arm64 (tan-aarch64-apple-darwin, sha256 183b28dc310c1def8b05af1fb7d84eb7ffdd9e445ea2188b2b3ee982ba3f0669), /usr/bin/time -p tan --version, five consecutive runs:

13.25 s
19.35 s
19.35 s
18.58 s
19.74 s

For reference on the same host, same shell:

git --version        0.01 s
python3 -c pass      0.03 s

--version is the cheapest possible command — it does no I/O, no network, no SDK resolution. So this is pure process startup, and every subcommand pays it. There is no warm path: repeat runs are not faster, and the first run was actually the fastest of the five.

Cause

The binary is a PyInstaller onefile bundle. Confirmed:

• strings on the executable contains pyi-runtime-tmpdir and PyInstaller's PKG-archive error string.
• While a command is running, a fresh extraction directory exists — /var/folders/dh/…/T/_MEIYC8HRM, 15 entries — and it is gone afterwards.

So each invocation unpacks 14 MB of Python runtime plus shared libraries into a new temp directory, runs, and deletes it. On macOS every extracted .dylib/.so is unsigned once written (the parent's ad-hoc signature does not cover the extracted copies), so the OS inspects them individually on load. That is where the ~19 s goes.

Signature state, for completeness:

$ codesign -dv ~/.local/bin/tan
CodeDirectory v=20400 size=110693 flags=0x2(adhoc) hashes=3453+2 location=embedded

$ spctl -a -vv ~/.local/bin/tan
/Users/…/.local/bin/tan: rejected

$ xattr -l ~/.local/bin/tan
(empty — no com.apple.quarantine, so this is NOT the download-quarantine case)

Why this matters more than it looks

A 19-second --version is not a slow tool, it is an unusable one. Every place tan is invoked repeatedly pays it in series:

• the VS Code extension, which shells out per keystroke-ish interaction;
• tan build over a multi-slice plan;
• CI jobs that call several subcommands (clean-host.yml runs four in a row — a large part of that job's wall-clock is this, not the assertions);
• anyone exploring the CLI, where --help on a few subcommands is a minute of waiting.

It also silently distorts every timing-based judgement made about the tool so far.

Directions

Roughly in order of effort/benefit — the first is the standard remedy for exactly this:

1. Ship --onedir instead of --onefile. Extraction happens once at install time rather than on every run; startup drops to normal Python-import cost. Costs: the asset becomes a tarball/zip rather than a single file, and install.sh must unpack it and place a launcher. This is what the size of the win argues for.
2. Sign and notarize the macOS binaries. Ad-hoc → Developer ID + notarization would let the OS trust the extracted libraries. Helps macOS; does nothing for the re-extraction cost itself, and does not help Linux.
3. Set a stable pyi-runtime-tmpdir so the extraction directory is reused across runs rather than recreated. Cheapest change, but it caches security-sensitive extracted binaries in a fixed location — wants thinking about before adopting.

Not proposing a fix here — the packaging decision is scripts/build_binary.sh's and has release-asset consequences (install.sh, checksums.txt, the clean host (published asset) job all assume one file per target).

Reproduce

curl -fsSL https://raw.githubusercontent.com/alplabai/tan-cli/main/install.sh | sh -s -- --version v0.5.0-rc3
/usr/bin/time -p tan --version

Reported after a full command sweep of rc3 on a real host; timing was measured because a user reported the CLI felt "extremely slow", and the number turned out to be far worse than "felt".

[alpCaner]

Confirmed on two more platforms, and the diagnosis holds. I measured the
published v0.5.0-rc4 assets (checksums verified against the release's own
checksums.txt; gh attestation verify passes and names commit
fbbea03d6b31ccc2672e0b52dec126b72520f979, the tagged commit):

platform	tan --version	git --version, same host
macOS arm64 (your rc3 measurement)	13.25 / 19.35 / 19.35 / 18.58 / 19.74 s	0.01 s
Windows x64 (rc4, published)	1.19 / 1.07 / 1.08 / 1.07 / 1.05 s	0.08 s
Linux x64 (rc4, published)	0.51 / 0.43 / 0.44 / 0.37 / 0.36 s	0.01 s

So the re-extraction tax is real on every platform — Linux is already ~40×
git, Windows ~14× — and macOS is a further ~40× on top of Linux. That extra
factor is specific to what you identified: the extracted .dylibs are not
covered by the parent's ad-hoc signature, so each is inspected individually on
load. It is not a macOS-only bug; macOS is where an existing cost becomes fatal.

Decision: direction 1, --onedir

Taken as a product decision rather than a packaging preference.

tan is a tool an embedded developer invokes constantly — the VS Code
extension shells out per interaction, a multi-slice tan build calls it
repeatedly, clean-host.yml chains four subcommands. Startup cost is paid on
every one of those, in series. A CLI that cannot answer --version faster than
a human notices is a tool people route around.

The other two directions were considered and rejected as the primary fix:

• Stable pyi-runtime-tmpdir is the cheapest change and I am not taking
  it. It caches extracted, executable .so/.dylib files in a fixed,
  predictable path — anyone who can write there wins before any signature check
  runs. That is an acceptable trade for a personal tool and not one to ship to
  customers.
• Sign + notarize is worth doing and does not fix this. It removes the
  per-dylib verification cost on macOS but not the re-extraction, and does
  nothing for Linux or Windows, both of which are already an order of magnitude
  off. Tracked separately below.

Consequences, so they move together

release.yml's asset contract becomes one archive per target rather than one
file. Everything that assumes one-file-per-target has to change in the same
slice:

• scripts/build_binary.sh — --onefile → --onedir
• release.yml — archive the dist dir; checksums.txt covers the archives
• install.sh — unpack and place a launcher instead of chmod +x
• the clean host (published asset) job — fetch and unpack
• alp-sdk-vscode's releaseAssetForTarget (src/alpCli/service.ts) —
  cross-repo. Its target→filename table and its download path both assume a
  single binary. That repo's pin is 0.5.0-rc4 today, so it keeps working
  against the current shape; the pin bump and the asset-shape change must land
  together or the extension's download 404s at runtime, not at build time.

Also worth doing, separately

spctl -a -vv reporting rejected is a bad first impression on macOS even
once startup is fixed. Developer ID signing + notarization needs an Apple
Developer account and CI secrets, so it is its own piece of work rather than a
rider on this one.

Thanks for measuring it rather than reporting "feels slow" — the gap between
those two is the whole issue.

[alpCaner]

Fixed in #352 — but the platform you filed it against is the one platform I
could not verify on, so I am not claiming it closed until you re-measure.

What changed

--onefile → --onedir, so extraction happens once at install time instead of
on every invocation. Each target now ships one archive (.zip on win32,
.tar.gz elsewhere) and install.sh / install.ps1 unpack it and place a
launcher.

What I measured, and where

Proven before the pipeline was rewritten — same commit, same host, 5 runs:

	tan --version
--onefile	0.890 / 0.876 / 0.867 / 0.871 / 0.898 s (mean 0.880 s)
--onedir	0.301 / 0.306 / 0.305 / 0.326 / 0.449 s (mean 0.337 s)

Windows only. I have no Mac, so the 13–19 s → ? number — the one that
actually mattered — is unverified.

The regression gate

python/tests/conformance/test_packaged_binary.py now fails if --version
exceeds a 0.6 s budget. Threshold picked from 10-run measurements (onedir
0.274–0.340 s, onefile 0.833–0.875 s) and validated against the known-bad
artifact: passes at 0.297 s on the onedir build, fails at 0.94 s against a real
--onefile build of the same commit. Not inferred.

Worth saying plainly: the e2e harness would never have caught this. It
asserts correctness, not latency — which is exactly how a 19 s startup shipped
through four RCs unnoticed. That gap is now closed by the budget test.

What I'd like from you

Once a release publishes archives, the same five-run measurement on the same
macOS arm64 host:

/usr/bin/time -p tan --version

Two macOS-specific things I cannot reason about from here, and would rather you
observe than have me guess:

1. First-run cost after install. Extraction now happens once, so the first
   invocation after install.sh may pay a one-off Gatekeeper/amfid pass over
   the extracted .dylibs. Steady-state is what matters, but if run 1 is
   pathological that is worth knowing.
2. spctl -a -vv still reports rejected — ad-hoc signature. Unchanged by
   this fix. Developer ID signing + notarization needs an Apple Developer account
   and CI secrets, so I left it as its own piece of work rather than a rider.
   Say the word if you want it opened as an issue.

Leaving #349 open until that measurement lands.

Also fixed in the same slice

install.ps1 still named tan-x86_64-pc-windows-msvc.exe, which release.yml
no longer publishes — every Windows user running the documented installer would
have taken a 404. And verify_binary.sh's CA-trust check
(grep cacert.pem "$BIN") returns nothing under onedir because the bundle moved
to _internal/ — that guard exists because #304 shipped an asset with no CA
bundle and TLS died everywhere, so it was re-pointed and proven both ways:
passes intact, fails with no certifi CA bundle at .../_internal/certifi/cacert.pem
when the bundle is moved aside.

[alpCaner]

Measured on the merged dev freeze (ac79d4c)

--onedir is in and measured on two of the three platforms. Numbers, not adjectives.

Linux — pristine ubuntu:24.04 container, --onedir freeze unpacked from the release tarball, tan --version:

run 1  317 ms      run 6  313 ms
run 2  317 ms      run 7  324 ms
run 3  312 ms      run 8  321 ms
run 4  324 ms      run 9  307 ms
run 5  326 ms      run 10 309 ms
---- mean over 10: 317 ms

tan doctor --format json (a real command, no SDK on the host): 307 / 310 / 310 ms.

Windows — same freeze shape, tan.exe --version: 335 / 337 / 337 / 352 / 350 ms.

The payload is 24 MB in _internal/.

Why the spread matters more than the mean

The --onefile signature was re-extraction on every invocation — a fixed cost paid per run, which is why --version cost the same as a real command. Across 10 consecutive runs the spread here is 307–326 ms, and doctor costs no more than --version. Nothing is being re-extracted; this is interpreter start plus imports.

For context, alp-sdk-vscode's version probe budget is timeout: 3000 (vscodeAdapter.ts:1406). At ~317 ms Linux / ~350 ms Windows there is roughly a 9x margin. The --onefile build blew straight through it.

What is still not measured

macOS. The 13.25–19.74 s that made this a release blocker was measured there, and the cause was macOS-specific: each extracted .dylib is unsigned (the parent's ad-hoc signature does not cover extracted copies), so Gatekeeper re-verified every one of them on every launch. Linux and Windows have no equivalent per-file verification, so their numbers — good as they are — do not answer the question this issue was filed about.

I have no Mac, so I cannot close this honestly. It needs one run of tan --version on tan-x86_64-apple-darwin.tar.gz or tan-aarch64-apple-darwin.tar.gz from the first archive release. If it lands anywhere near these numbers, this closes; if it does not, the fix is incomplete on the platform that motivated it.