perf: emit less generated runtime code - #15327
Conversation
|
📝 Benchmark detail: Open
Base persistent cache hit rate: 👍 Current persistent cache hit rate: 👍 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4203406f97
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| let artifact = &compilation.build_chunk_graph_artifact; | ||
| let mut worker_entry = false; | ||
| for chunk_ukey in artifact.chunk_graph.get_module_chunks(module) { |
There was a problem hiding this comment.
Restrict the rewrite to actual worker entry modules
When a classic worker imports another CommonJS module that uses top-level this (for example, this.value = 1), that dependency is also returned by get_module_chunks and shares the worker's single runtime, so this function rewrites its this to the worker global as well. Only the worker entry module should receive script-level global semantics; imported modules still execute as CommonJS module factories where top-level this aliases their exports. Check that module is among the chunk's entry modules (and use its associated entrypoint) rather than treating every module placed in a worker chunk as an entry.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 7052b2f. is_worker_entry_this now requires the module to be present in the chunk entry-module map and reads that entry module associated entrypoint. Imported CommonJS modules therefore retain exports semantics. I also added a normal/RuntimeMode regression where a classic worker imports a CommonJS dependency using top-level this.
📦 Binary Size-limit
❌ Size increased by 8.00KB from 68.12MB to 68.13MB (⬆️0.01%) |
Rsdoctor Bundle Diff AnalysisFound 5 projects in monorepo, 5 projects with changes. 📊 Quick Summary
📋 Detailed Reports (Click to expand)📁 popular-libsPath:
📦 Download Diff Report: popular-libs Bundle Diff 📁 react-10kPath:
📦 Download Diff Report: react-10k Bundle Diff 📁 react-1kPath:
📦 Download Diff Report: react-1k Bundle Diff 📁 react-5kPath:
📦 Download Diff Report: react-5k Bundle Diff 📁 ui-componentsPath:
📦 Download Diff Report: ui-components Bundle Diff 🤖 AI Degradation Analysis (Click to expand)📁 popular-libs📊 Size ChangesTotal bundle size decreased by 186 bytes (0.01%) 🎉. No individual assets exceeded the regression threshold (>5% or >10 KB). 🔍 Root Cause Analysis
|
| Asset / Chunk | Baseline | Current | Δ Size | Δ % | Initial? |
|---|---|---|---|---|---|
| No significant regressions detected 🎉 | - | - | - | - | - |
🔍 Root Cause Analysis
- Minor size reduction driven by changes in
src/index.jsx(parsed: 1,115 → 1,094 bytes). - No new dependencies added;
react-5kpackage size remained stable.
⚠️ Risk Assessment
Overall severity: Low
- Total bundle size decreased by 250 bytes (2,793,975 → 2,793,725), with initial chunk also reduced (525,536 → 525,286 bytes).
💡 Optimization Suggestions
- Maintain current tree-shaking configuration; no immediate action required.
- Continue monitoring
react-5kpackage (~523 KB parsed) as it dominates the bundle composition. - Verify gzip sizes remain consistent in production builds.
Analysis by qwen3.5-plus
📁 ui-components
📊 Size Changes
No significant regressions detected 🎉.
(Note: Total JS size decreased slightly by 186 bytes.)
🔍 Root Cause Analysis
- No specific module or package changes detected in the diff data (
modulesandpackagesarrays are empty). - Total JS size reduced marginally from 5,023,373 bytes to 5,023,187 bytes (-0.0037%).
- CSS and asset counts remain unchanged.
⚠️ Risk Assessment
Overall severity: Low
- Initial chunk size is effectively stable (5,023,187 bytes); negligible delta implies no impact on load performance.
💡 Optimization Suggestions
- No immediate actions required; bundle health is stable.
- Continue monitoring future diffs for new dependency additions that may exceed thresholds.
- Verify source control changes to confirm why aggregate size shifted without module-level detection.
Analysis by qwen3.5-plus
Generated by Rsdoctor GitHub Action
Merging this PR will regress 1 benchmark
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Simulation | rust@concatenate_module_code_generation |
44.4 ms | 45.6 ms | -2.56% |
| ⚡ | Simulation | rust@create_module_hashes |
8.7 ms | 8.3 ms | +4.26% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing perf/sync-webpack-21803-runtime (7052b2f) with main (a963c03)
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. ↩
4203406 to
7052b2f
Compare
|
📝 Benchmark detail: Open
Base persistent cache hit rate: 👍 Current persistent cache hit rate: 👍 |
Summary
thissemantics for classic worker entries, including code-generation hash inputs when the same module is used by worker and non-worker runtimes.onChunksLoadedpriority handling, modern runtime syntax, externals, and classic/module/shared-worker behavior, then refresh affected output snapshots.These paths run while generating runtime modules and dependency code for many chunks. Reusing the rendered
Stringwithtruncateavoids an extra allocation, while the shorter helpers reduce emitted raw and compressed JavaScript. The worker-specific lookup is only reached for CommonJS dependencies containing top-levelthis: it iterates chunks containing the module, requires a direct hit in the chunk's entry-module map, and reads only that entry module's associated entrypoint for the current single runtime. Imported CommonJS dependencies therefore retain module-factory top-levelthissemantics, and ordinary modules do not trigger a chunk-group scan. The expected benefit is smaller generated runtime code and fewer temporary code-generation allocations; this does not claim faster generated-code execution.Related links
thisin a classic worker entry as its global scope webpack/webpack#21720Checklist