Summary
Reduce initial load time when opening large JSONL files in the extension.
Problem
Initial open of large files currently takes ~1 second or more, which feels sluggish compared to VS Code’s native text viewer (tens of milliseconds). Users expect near-instant feedback when opening files. * this is actually constant regardless of the file size and seems to have to do with the extension.
Proposed Solution
- Audit the extension’s startup pipeline:
- Activation, provider creation, WebView creation, HTML generation, JS initialization, initial messaging, etc.
- Defer expensive work:
- Lazy-load tokenization, Markdown rendering, and heavy parsing until needed or when a row becomes visible.
- Minimize HTML/JS payload:
- Avoid giant HTML strings; consider modularizing or reducing DOM size.
- Add simple performance logging (dev mode) to identify bottlenecks.
Acceptance Criteria
- Opening a large test JSONL file is subjectively “snappy” (<300–400 ms on a typical machine) the first time.
- Profiling shows no single step is egregiously slow.
- Lazy behavior is confirmed (e.g., token counts or markdown are not computed until requested/visible).
Summary
Reduce initial load time when opening large JSONL files in the extension.
Problem
Initial open of large files currently takes ~1 second or more, which feels sluggish compared to VS Code’s native text viewer (tens of milliseconds). Users expect near-instant feedback when opening files. * this is actually constant regardless of the file size and seems to have to do with the extension.
Proposed Solution
Acceptance Criteria