perf(@angular/build): process batch locales sequentially in i18n inliner worker - #34211
Merged
Merged
Conversation
…ner worker Executing batch locales concurrently via Promise.all within a single worker thread provided no concurrency benefit because inlining operations (MagicString transformations and source map decoding/remapping) are predominantly synchronous and CPU-bound on Node's single-threaded event loop. Holding concurrent MagicString instances, intermediate AST slices, and decoded source map mappings simultaneously inflated peak worker heap and RSS (especially for smaller chunks where up to 8 locales are processed in a single batch). Switching to sequential iteration allows intermediate transformation and mapping structures to be garbage-collected between locales, reducing peak RSS and slightly improving throughput due to reduced GC pressure.
… files in i18n inliner Dominant files (such as main.js or other large bundles >= 70% of max file size) previously sharded their locales across all available workers in the pool. On high-core machines, this dispatched heavy AST parsing and sourcemap remapping simultaneously across all worker threads, monopolizing the pool, causing memory bus/cache contention, and spiking peak V8 heap and RSS. A MAX_DOMINANT_WORKERS constant of 4 now caps the number of worker threads concurrently processing a single dominant file. Additionally, when multiple files exist in the window, workers are dynamically allocated to guarantee that at least one worker thread is always available to process smaller chunks concurrently without starvation. A new multi-dominant scenario has also been added to the benchmark suite to measure throughput and memory under multi-bundle workloads.
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 memory usage and concurrency management during i18n inlining. In i18n-inliner-worker.ts, parallel processing of locales via Promise.all is replaced with a sequential for...of loop to reduce peak memory. In i18n-inliner.ts, a concurrency cap (MAX_DOMINANT_WORKERS = 4) is introduced for dominant files to prevent V8 heap and RSS explosion on high-core machines, while also ensuring at least one worker remains available for smaller chunks to avoid starvation. Additionally, a new benchmark scenario (multi-dominant) is added to test these changes under contention. There are no review comments, so no further feedback is provided.
clydin
added
target: minor
alan-agius4
approved these changes
Sep 30, 2026
alan-agius4
added
action: merge
Member
Author
|
This PR was merged into the repository. The changes were merged into the following branches:
|
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
2 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.
Executing batch locales concurrently via Promise.all within a single
worker thread provided no concurrency benefit because inlining operations
(MagicString transformations and source map decoding/remapping) are
predominantly synchronous and CPU-bound on Node's single-threaded event loop.
Holding concurrent MagicString instances, intermediate AST slices, and
decoded source map mappings simultaneously inflated peak worker heap and RSS
(especially for smaller chunks where up to 8 locales are processed in a single
batch).
Switching to sequential iteration allows intermediate transformation and
mapping structures to be garbage-collected between locales, reducing peak RSS
and slightly improving throughput due to reduced GC pressure.