🩹 [Patch]: Module startup is faster and performance checks are reproducible (#69)
Module startup is now faster and performance regressions are easier to catch because the import path was optimized and repeatable benchmark tooling is included in the repository.
Changed: Faster module startup
Cold module import is significantly faster in fresh PowerShell sessions, and parallel session startup is also reduced, so common CLI and automation entry points spend less time on initialization.
| Metric | Before | After | Δ |
|---|---|---|---|
Cold import (fresh pwsh) |
66.7 ms | 42.3 ms | −37% |
| Parallel runspaces ×4 (import + roundtrip) | 43.5 ms | 28.1 ms | −35% |
| Per-op (seal / open / keypair) | 104 / 104–121 / 49 µs | 99 / 100–112 / 46 µs | −4–7% |
Changed: Reproducible performance verification
The repository now includes benchmark scripts for cold import timing, per-operation stopwatch measurements, and Profiler traces, so performance changes can be validated the same way in future PRs.
Technical Details
- Kept the
Import-Moduleassembly-load approach after evaluating alternatives becauseAdd-Type -PathandAssembly.LoadFromwere slower on measured runs. - Optimized import-time initialization by using a direct runtime path combine operation and avoiding redundant interop calls for fixed
crypto_boxsize constants. - Added
tools/benchmarkscripts for local module assembly, stopwatch benchmarks, import benchmarks, and profiler traces, then cleaned them to satisfy linter rules. - Public interfaces remain unchanged, full test suite remains green, and multi-session behavior (parallel runspaces/processes) is preserved.
- Implementation progress for the linked issue is complete: benchmarked load strategies, selected the fastest safe path, and documented the decision in this PR.
Related issues
- Fixes #58