perf(@angular/build): read rendered module length once per module in chunk optimizer - #34045
Merged
clydin merged 3 commits intoSep 8, 2026
Merged
Conversation
…chunk optimizer When converting the chunk optimizer output into an esbuild-compatible metafile, the rendered length of each module was read inside the loop over the module's original inputs. The `renderedLength` property of a rolldown rendered module is a lazy getter that transfers the full module code from native memory on every access. Since each module in this pass is an entire esbuild output chunk, a main chunk of 17 MB with 3,588 inputs resulted in roughly 62 GB of string copies and around 150 seconds spent in `bundleOutputToEsbuildMetafile`, while the rolldown bundling itself took 3 seconds. Read the rendered length once per module before iterating its inputs. The generated metafile is unchanged. On the affected application the `OPTIMIZE_CHUNKS` phase drops from 179 seconds to 4 seconds and the total production build from 234 to 55 seconds. Fixes angular#34044
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
angular-robot
Bot
added
area: performance
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request optimizes the chunk optimizer by caching the renderedModule.renderedLength value in a local variable before entering the loop. This avoids repeatedly accessing the lazy getter, which triggers expensive native memory transfers of the entire module code on each iteration. I have no feedback to provide as there are no review comments.
Removed comments explaining the performance impact of accessing the rendered length in the chunk optimizer.
clydin
reviewed
Sep 8, 2026
1 task
clydin
added
the
action: cleanup
…r.ts Co-authored-by: Charles <19598772+clydin@users.noreply.github.com>
alan-agius4
added
merge: squash commits
clydin
approved these changes
Sep 8, 2026
Member
clydin
added a commit
that referenced
this pull request
Sep 8, 2026
…chunk optimizer (#34045) * perf(@angular/build): read rendered module length once per module in chunk optimizer When converting the chunk optimizer output into an esbuild-compatible metafile, the rendered length of each module was read inside the loop over the module's original inputs. The `renderedLength` property of a rolldown rendered module is a lazy getter that transfers the full module code from native memory on every access. Since each module in this pass is an entire esbuild output chunk, a main chunk of 17 MB with 3,588 inputs resulted in roughly 62 GB of string copies and around 150 seconds spent in `bundleOutputToEsbuildMetafile`, while the rolldown bundling itself took 3 seconds. Read the rendered length once per module before iterating its inputs. The generated metafile is unchanged. On the affected application the `OPTIMIZE_CHUNKS` phase drops from 179 seconds to 4 seconds and the total production build from 234 to 55 seconds. Fixes #34044 * Remove performance comments in chunk-optimizer.ts Removed comments explaining the performance impact of accessing the rendered length in the chunk optimizer. * Update packages/angular/build/src/builders/application/chunk-optimizer.ts Co-authored-by: Charles <19598772+clydin@users.noreply.github.com> --------- Co-authored-by: Charles <19598772+clydin@users.noreply.github.com> (cherry picked from commit f1afa60)
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
3 participants
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.
PR Checklist
Please check to confirm your PR fulfills the following requirements:
No test added: the change is a pure performance fix with no behavioral difference. The generated metafile is byte-identical before and after (verified by replaying
optimizeChunkson a dumped esbuild result and comparing the serialized metafile andinitialFiles). Happy to add a spec if you can point me at a suitable harness forchunk-optimizer.PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: #34044
In
bundleOutputToEsbuildMetafile,renderedModule.renderedLengthis read inside the loop over each module's original inputs. On rolldown's rendered module object that property is a lazy getter (bindingRenderedModule.code?.length) which transfers the entire module code from native memory on every access. Because each "module" in the chunk optimizer is a whole esbuild output chunk, a 17 MB main chunk with 3,588 inputs performs 3,588 copies of a 17 MB string (~62 GB). On the application in the linked issue this is ~157 s out of a ~161 sOPTIMIZE_CHUNKSphase, while the rolldown bundling itself takes ~3 s. Rolldown also emits a misleading[PLUGIN_TIMINGS]warning about theangular-bundleplugin as a side effect.What is the new behavior?
The rendered length is read once per module before iterating its inputs. Measured on the same application and machine (production configuration,
sourceMap: true):DURATION[OPTIMIZE_CHUNKS]ng buildOutput files are byte-identical (same file list, same SHA-256 for every JS and CSS file).
Does this PR introduce a breaking change?
Other information
A follow-up on the rolldown side could cache
codeintransformToRenderedModule, but this hoist removes the cost regardless of the rolldown version. The[PLUGIN_TIMINGS]warning still fires after the fix because rolldown compares plugin time against a near-zero link stage when the inputs are a few hundred pre-bundled chunks; passingchecks: { pluginTimings: false }torolldown()in the optimizer would silence it, but that is left out of this PR.🤖 Generated with Claude Code