The cache plan added in d65f8b19 was meant to shave ~5min off Windows
install time, but a controlled rerun on the same SHA shows it doesn't.
Side-by-side timing of the install step (cache miss vs cache hit on the
same Windows Update CI job, same workflow, same source):
cache miss (385s) | cache hit (450s, +65s slower)
----------------------- | -----------------------------
Cache restore 1s | 83s (76s Studio venv + 4 + 3)
Frontend build 159s | 204s ("Frontend source changed since
| last build -- rebuilding...")
PyTorch + 9 deps 81s | 95s
llama.cpp install 39s | 13s ("prebuilt up to date and validated")
Cache save (post) 17s | 0s (no upload, hash matched)
Root causes:
1. The Studio venv cache is a no-op. install.ps1 line 1097-1120 sees the
cached venv, calls Start-StudioVenvRollback to MOVE it aside as a
rollback backup, then unconditionally creates a fresh venv at line
1167. Cache restore costs 76s for a 398MB venv that is then thrown
away.
2. The frontend dist cache is a no-op. setup.ps1 line 1281-1296 checks
`LastWriteTime > $DistTime` for every source file. git checkout sets
all source mtimes to "now" while restored dist mtimes are from
cache-creation time, so the staleness check always wins and rebuilds.
3. Only the llama.cpp prebuilt cache works (saves ~26s). Not enough to
offset the other two.
Reverting the cache plan is safer than partially fixing it and waiting
for a follow-up to land. install.ps1 + setup.ps1 would both need
modification to make the cache useful, and that change touches all
platforms. The non-Windows mirrors of these workflows (-mac-, regular
linux) never had cache steps, so this revert restores parity.
The four other commits in this branch (Recents click bound, jq health
check, sys.stdio explicit handles, setup.ps1 stdout mirror, single-
process Chromium darwin-only, github_blob_to_raw netloc check) all
remain.
e1345d5f1b