perf: reuse SWC parser allocator during make#14795
Conversation
📦 Binary Size-limit
❌ Size increased by 4.00KB from 66.55MB to 66.56MB (⬆️0.01%) |
|
📝 Benchmark detail: Open
Base persistent cache hit rate: 👍 Current persistent cache hit rate: 👍 |
Merging this PR will not alter performance
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Simulation | rust@create_chunk_assets |
1.4 ms | 1.5 ms | -2.99% |
| ⚡ | Simulation | rust@create_module_hashes |
8.5 ms | 8.3 ms | +2.33% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing perf/reuse-swc-allocator (8c9417a) with main (786dec5)
Footnotes
-
47 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
Summary
JavaScript module parsing runs once per module during make, so repeated allocator setup and backing-buffer allocation scale with module count. Retaining the arena per worker removes that repeated allocation churn while preserving the existing AST lifetime boundary: all arena-backed values are consumed before the guard resets the allocator.
The guard also resets and returns the arena on early error returns. Reentrant parsing can temporarily create another allocator, but only one arena is retained per worker, preventing the cache from growing without bound.
Expected impact: fewer system allocations and frees in the make-stage JavaScript parser hot path, especially for compilations with many modules.
Related links
N/A
Checklist