perf: use disk logs with in-memory metadata#400
Draft
webfansplz wants to merge 2 commits into
Draft
Conversation
commit: |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR refactors the Vite inspect collector to persist large transform payloads and plugin-call logs to disk while keeping query/metadata in memory, reducing memory pressure and improving responsiveness during heavy transform activity.
Changes:
- Introduces a disk-backed inspect store (
payloads.bin+plugin-calls.bin) with batched, async persistence and invalidation-aware reclamation. - Updates inspect collection + RPC dump inputs to operate on async module ID enumeration and adds request-staleness tracking to avoid recording invalidated work.
- Extends plugin-call data with
graphModuleIdresolution for more accurate UI linking, and adds a new structured diagnostic (VDT0003) + docs.
Reviewed changes
Copilot reviewed 22 out of 23 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| pnpm-lock.yaml | Updates tar dependency version in the lockfile. |
| packages/vite/src/node/rpc/functions/vite-resolve-id.ts | Adjusts RPC dump input collection to await async module ID enumeration. |
| packages/vite/src/node/rpc/functions/vite-get-module-transform-info.ts | Same async module ID enumeration change for transform-info RPC dump inputs. |
| packages/vite/src/node/inspect/utils.ts | Removes raw from parsed errors and makes module ID enumeration async via environment APIs. |
| packages/vite/src/node/inspect/types.ts | Adds optional graphModuleId on plugin-call records. |
| packages/vite/src/node/inspect/store/types.ts | Defines the inspect store interfaces, batch stats, and persisted record shapes. |
| packages/vite/src/node/inspect/store/plugin-calls.ts | Adds a binary plugin-call archive (memory or file-backed) with invalidation-aware slot reuse. |
| packages/vite/src/node/inspect/store/payload.ts | Adds a payload archive (memory or file-backed) with range allocation + reclamation. |
| packages/vite/src/node/inspect/store/index.ts | Implements the main queued/batched inspect store with flush/close semantics and metrics APIs. |
| packages/vite/src/node/inspect/server.ts | Adds AsyncLocalStorage-based request tracking + smarter invalidation behavior. |
| packages/vite/src/node/inspect/plugins.ts | Adds async plugin metrics/details powered by the new store and resolves graphModuleId. |
| packages/vite/src/node/inspect/plugin.ts | Creates and manages on-disk inspect storage under Vite’s cache dir; wires stale-request checks. |
| packages/vite/src/node/inspect/module.ts | Moves module list + module transform info logic into a dedicated helper module. |
| packages/vite/src/node/inspect/hijack.ts | Skips recording transforms/loads/resolveIds for stale transform requests. |
| packages/vite/src/node/inspect/context.ts | Refactors environment context to use the new async store-backed model. |
| packages/vite/src/node/diagnostics.ts | Adds diagnostic code VDT0003 for inspect storage failures. |
| packages/vite/src/node/tests/inspect-server.test.ts | Adds coverage for invalidation behavior and request-context staleness tracking. |
| packages/vite/src/node/tests/inspect-plugin.test.ts | Adds coverage for plugin lifecycle closing of inspect storage. |
| packages/vite/src/node/tests/inspect-context.test.ts | Updates/expands tests for async APIs, file-backed storage, batching, reuse, and GC behavior. |
| packages/vite/src/app/components/data/PluginDetailsTable.vue | Uses graphModuleId (when available) for graph navigation links. |
| packages/vite/src/app/components/data/PluginDetailsLoader.vue | Uses graphModuleId (when available) for graph navigation links in the tree view. |
| docs/errors/VDT0003.md | Adds documentation for the new inspect storage diagnostic. |
| docs/errors/index.md | Registers VDT0003 in the diagnostics index. |
Files not reviewed (1)
- pnpm-lock.yaml: Generated file
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
012f72c to
bee29fc
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
This PR updates the persistence approach after evaluating a database-backed replacement for the previous memory-based solution.
I first tried using a DB for both reading and writing runtime data, but found that Vite core generate data much faster than the DB can persist it. Under that write pressure, the DB approach becomes a bottleneck and is not viable for this use case.
After testing and comparing alternatives, this PR adopts disk logs with in-memory metadata instead. This keeps high-volume writes append-friendly on disk while allowing the runtime to maintain fast metadata access in memory, which better matches the data flow and performance profile of Vite core.
Benchmark
Compared
perf/inspect-vite@012f72c(this PR) withmain@67cf430branch using 10,000 modules, 200 plugins, and 160,000 plugin calls. Results are medians from seven fresh Node.js processes using the production disk-backed storage path.Results
Processing Time
mainIngestion throughput drops from 1.17M to 662K events/s. For this workload, the total ingestion cost increases by approximately 104 ms.
Memory
mainConclusion
All runs returned the expected 10,000 modules, 200 plugin metrics, 800 calls for the selected plugin, and 13 transforms for the selected module.