Profile Rust parseExtractionMs before next optimization

[jununfly]

This was generated by AI during triage.

Parent

• Post-PRD optimization tracker for Rust indexing performance #165
• Phase 23: Optimization architecture cleanup #218

What to build

Profile the Rust parseExtractionMs bucket before opening another bounded optimization implementation issue.

Phase 23 selected this as the next #165 step because the cleaned evidence comparison ranks parseExtractionMs as the largest Rust-owned remaining bucket after Phase 22. This issue is diagnostic/profiling first. It should split parseExtractionMs into actionable subsegments and decide whether the cost is implementation-owned, grammar/parser-owned, source-shape-driven, or orchestration-driven.

Do not implement a performance optimization in this issue unless the diagnostic result exposes a trivial instrumentation-only fix required to make the profile trustworthy.

Acceptance criteria

• Add or reuse profile diagnostics that split parseExtractionMs into actionable parser/extraction subsegments.
• Keep diagnostics local to benchmark/profile artifacts; do not promise long-term public API stability for new fields.
• Run a reduced or targeted fixture profile to prove the new breakdown is populated.
• Run targeted smoke/profile evidence on current artifacts or a current target sufficient to choose one next step.
• Record RSS or an unavailable reason.
• Record sufficiency if the touched path can affect index/read/explore behavior.
• Write a decision artifact under docs/benchmarks/.
• Decide exactly one next step: one bounded parseExtractionMs optimization candidate, one no-go reason, or one narrower profiling issue.
• Do not run a full VS Code sparse scoreboard by default.
• Do not change default user-visible indexing behavior.
• Do not change SQLite schema or MCP behavior.
• Do not claim Rust default rollout readiness.

Blocked by

• Phase 23.5: Decide next post-PRD optimization step #223

[jununfly]

This was generated by AI during triage.

Status update on 2026-06-18:

This remains open as a follow-up profiling candidate, not a blocker for the rust-hybrid first-user release slices completed so far.

Current context:

• Phase 4 diagnostic bundles are complete.
• Phase 5 release-like packaged rust-hybrid smoke is complete.
• Performance optimization is still intentionally tracked separately from first-user release usability gates.
• If this issue is picked up next, it should be evaluated against the current evidence pipeline and Post-PRD optimization tracker for Rust indexing performance #165 rather than treated as part of Phase 5 packaged smoke.

No code changes were made for this issue in the latest update.

[jununfly]

This was generated by AI during triage.

Update from the 2026-06-19 rust-hybrid default-path performance A/B pass (#287-#290): this issue remains open and valid, but it was not selected for that bounded implementation slice.

Evidence:

• Baseline: docs/benchmarks/2026-06-19-rust-hybrid-indexing-performance-ab-baseline.md
• After/decision: docs/benchmarks/2026-06-19-rust-hybrid-indexing-performance-ab-after.md

Reason:

• On VS Code sparse, baseline parseExtractionMs was 40,233ms, while rustCore.sqliteWriteMs was 124,488ms. The selected single candidate therefore targeted Rust SQLite write time.
• After the kept candidate, VS Code sparse rustCore.sqliteWriteMs moved to 54,887ms and parseExtractionMs was 40,452ms.

Interpretation:

• This pass neither closes nor rejects Profile Rust parseExtractionMs before next optimization #224.
• Profile Rust parseExtractionMs before next optimization #224 should stay available as a future profiling candidate, especially now that Rust write time is materially lower and parse extraction is a more visible Rust-owned bucket.