Windows perf: WindowsRegistry locator is fully sequential and re-walks both hives on every refresh

[eleanorjboyd]

Summary

The WindowsRegistry locator iterates HKLM, then HKCU, serially — no thread::scope, unlike pet-pyenv / pet-homebrew / pet-conda. Per install it does multiple registry reads plus inline filesystem stats and norm_case calls (each a real GetLongPathNameW syscall — see #ISSUE-3). The cache is per-refresh only: find() calls self.clear() first, so every refresh RPC re-walks both hives from scratch.

Likely contributes to the steady-state Windows p90, less likely to dominate the heavy tail than #ISSUE-1 but still material — especially if the extension calls refresh repeatedly within a session.

Full investigation: docs/windows-perf-investigation.md (Issue 2).

Where

• crates/pet-windows-registry/src/environments.rs — get_registry_pythons (~L46–78) and get_registry_pythons_from_key_for_company (~L83–218)
• crates/pet-windows-registry/src/lib.rs — cache + self.clear() at top of find() (~L33–53)

What it does today

• HKLM and HKCU walked sequentially on a single thread.
• For each Software\Python\<company>\<install>: open_subkey × 2, get_value × 5, env_path.exists(), is_conda_env(env_path) (more stats), executable.exists(), plus 2× norm_case (each a GetLongPathNameW syscall).
• Cache is invalidated unconditionally at the top of find() — only deduplicates within a single refresh, never across refreshes.

Proposed fix

1. Parallelize HKLM and HKCU using thread::scope (matches the pattern already used in pet-pyenv, pet-homebrew, pet-conda).
2. Within a hive, parallelize per-company.
3. Reconsider the unconditional self.clear() at the top of find(). Registry installs rarely change within a session — invalidate only on configure (or via opt-in) so subsequent refresh calls reuse results.

Estimated change size: ~40 lines.

Telemetry follow-up

Split WindowsRegistry timing in RefreshPerformance into HKLM vs HKCU so the extension can confirm impact in production.