Investigate remaining zsh startup slowness (1.5-2s, not captured by zsh -i -c exit)

[rolfsormo]

What we know so far

After fixing the eager conda shell.zsh hook and a .zshrc.devboost double-source
bug this session, synthetic timing (zsh -i -c exit, and zprof) shows shell
initialization itself down to ~0.2s, dominated by zinit plugin loading (~55%) and
_mise_hook (~25%).

However, real-world observed time from opening a new terminal window/tab to a usable
prompt is still 1.5-2 seconds — a ~1.3-1.8s gap that zsh -i -c exit structurally
can't see, because it exits immediately without ever reaching an actual interactive
prompt render.

Suspects (not yet confirmed)

• iTerm2 shell integration handshake (~/.iterm2_shell_integration.zsh is sourced,
  179 lines) — may have its own async round-trip cost separate from zsh's own init.
• compinit/completion cache: found 9 different stale .zcompdump* files on this
  machine, tied to different old hostnames/machine names (Rolfs-2021-MBP,
  Rolf's MacBook Pro, Rolfs-MacBook-Pro, Rolfs-MacBook-Pro-2, two different
  macbookpro.lan PIDs). compinit's default hostname-based cache-file lookup may be
  missing the "right" cache or doing extra work because of this — worth checking
  whether it's silently doing a full rebuit (which stats every function in $fpath,
  a well-known multi-second cost) versus using a cache.
• Two active plugin managers (see the znap→zinit issue) doing genuinely redundant
  plugin-loading work, on top of whatever startup overhead each carries individually.
• Terminal-app-side rendering/GPU cost, unrelated to the shell at all — needs to be
  ruled in/out separately from anything zsh-side.

Next steps

• Get an accurate time-to-first-prompt measurement that isn't zsh -i -c exit (e.g.
  a precmd hook that timestamps and writes to a file, triggered from a genuinely
  fresh interactive shell — not a nested/synthetic one).
• Clean up stale .zcompdump* files and re-measure.
• Re-measure after the znap→zinit consolidation lands (should remove one full
  redundant plugin-manager init).
• If a large gap remains, profile iTerm2 integration and terminal-app-level startup
  separately from the shell itself.

Relates to

• The environment-health-checks module issue (stale .zcompdump as a checkable item).
• The znap→zinit consolidation issue (redundant plugin manager as a contributing cause).

[rolfsormo]

Update (2026-08-05): confirmed in a genuinely fresh terminal

Re-tested from a brand-new terminal window (not derived from any session shell), so
the earlier "stale inherited env from mid-migration" theory is ruled out as the sole
cause — startup is still slow in a clean environment.

Confirmed in the fresh shell:

• No oh-my-zsh remnants in $FPATH/env — the removal + .zshrc fix from the prior
  session are holding.
• The 11 stale hostname-suffixed .zcompdump-* files are still present (not yet
  cleaned up).
• ~/.zshrc.devboost:6 runs autoload -Uz compinit && compinit -u directly — this is
  devboost's own compinit call, separate from whatever zinit's annexes/_zinit
  compdef machinery do earlier in ~/.zshrc.

New finding, sharper than "two plugin managers doing redundant work": ~/.zshrc
(lines 1-40, pre-existing, not devboost-managed) also runs asdf
(. /opt/homebrew/opt/asdf/libexec/asdf.sh) alongside devboost's own mise activate zsh in .zshrc.devboost. Two version managers doing PATH/shim setup on
every shell start, not just two plugin managers. Also: ~/.codeium/windsurf/bin is
prepended to $PATH twice (lines 36 and 38).

This reframes the investigation: the dominant cost is very likely the pre-existing,
non-devboost ~/.zshrc content (zinit + annexes + duplicate plugins + asdf + misc
legacy tool inits from Android/Dart/Codeium tooling) executing before devboost's own
managed block even runs — not compinit itself, and not inherited stale env.

See #6 for the zinit/znap consolidation, which is now the most likely single biggest
lever. Recommend re-profiling with zprof in a clean pty+precmd harness only after
that lands, since compinit's real cost can't be isolated from the noise above it yet.

[rolfsormo]

Update (2026-08-08): root cause found and fixed — real ~80% reduction

Follow-up session dug into why the fresh-terminal gap persisted after the
zinit/asdf/nvm redundancy fixes (see #6/#7 history). Key methodology fix first:
all measurement must go through the real path iTerm2/Terminal actually use —
/usr/bin/login -fpl <user> /Applications/iTerm.app/Contents/MacOS/ShellLauncher --launch_shell, via a real pty (script -q /dev/null ...). Anything using zsh -i
directly, or a -c 'command' one-shot, skips real login-shell codepaths
(~/.zprofile, PAM, /usr/bin/login's own banner) and/or exits before the shell
ever reaches full interactive readiness — both produce misleadingly fast numbers.
Confirmed PAM itself (pam_opendirectory.so etc. in /etc/pam.d/login) is NOT a
meaningful cost (~78ms for the full auth+session flow, measured directly) — an
earlier same-session guess that it was got corrected and retracted.

Root cause of the remaining gap after the redundancy fixes: devboost's own
.zshrc.devboost template (modules/module_zsh.sh) called autoload -Uz compinit && compinit -u directly, before sourcing znap. But znap (~/.zsh-snap/scripts/ init.zsh) redefines compinit/compdef as no-ops the moment it loads, and installs
its own deferred, precmd-hook-based compinit into a different dumpfile
(~/.cache/zsh/compdump, vs devboost's ~/.zcompdump). Result: devboost's own
compinit -u call did a full, real completion rebuild (~300ms+) that was then
immediately superseded/wasted the moment znap loaded and took over — pure redundant
work, self-inflicted by devboost's own template, not the user's config.

Fix applied: removed the manual compinit -u call from module_zsh.sh's
generated template entirely; znap already owns completion init once sourced. Landed
alongside the legacy_shell module (zinit/znap, asdf/mise, nvm/mise dedup — see #6,
#7) in the same session.

Measured result (real machine, real login-shell path, zprof-confirmed clean —
no more compdump/compinit/compdef in the profile once znap's own dumpfile
settles after one expected one-time rebuild):

• Before any fixes this investigation: ~1.44s
• After zinit+asdf+nvm redundancy fixes alone: ~400-410ms avg
• After also removing devboost's duplicate compinit call: ~285-305ms steady

Overall ~80% reduction from where this investigation started. User confirms this
matches subjective experience — no longer bothersome, though still perceptible.

Remaining ~290ms: no single dominant cost anymore

Profiled breakdown at this point is spread thin, not concentrated:
_mise_hook/_mise_hook_precmd (~35-40ms combined), compaudit (~15-20ms),
@zinit-scheduler, .znap.multi/plugin loading, _direnv_hook, starship/atuin/fzf
inits — each individually small. This is structurally healthy (nothing being wasted)
but means further gains require a different lever than "find and remove one bad
thing."

Idea captured for later, not started: background/async compinit

Discussed defering compinit further than znap's current precmd-hook approach (which
still blocks the first prompt until it completes) — true backgrounding, where the
prompt appears immediately and completions become available moments later while the
user can already type (patterns exist for this: zsh-defer, zinit's wait ice
modifier, or a hand-rolled fork+sched/zle -F pickup).

Open concern raised: what happens if the backgrounded compinit doesn't finish quickly
— stalls, hangs, or genuinely takes seconds (e.g. a cold NFS-mounted $fpath entry,
a huge plugin set, disk contention)? A naive background-and-forget approach could
leave completions silently broken/stale with no feedback. Needs either: a
timeout/watchdog that falls back to "no completions yet, try again" gracefully, a
visible-but-unobtrusive indicator while it's still loading, or at minimum a documented
worst-case behavior. Not scoped or estimated — parking as a follow-up idea, not a
committed plan.

Status: parking further startup-perf work here

~80% reduction achieved and it's no longer the pressing issue. Revisit if it becomes
worth it again (e.g. if the remaining ~290ms starts to bother, or the
background-compinit idea above gets picked up).