Repository navigation
perf(@angular/build): avoid sharding intermediate files under worker surplus in i18n inliner - #34219
Merged
Merged
Conversation
…surplus in i18n inliner When the number of uncached files in an inlining window meets or exceeds the worker pool concurrency, the thread pool already has sufficient file-level parallelism to keep all workers fully utilized. Previously, all intermediate files (files between 100 KB and 70% of the maximum file size) were sharded into batches of half their locales regardless of the total file count. In applications with many chunks, this doubled the number of worker tasks and forced multiple worker threads to independently parse the same JavaScript file and decode the same source map. Intermediate files are now processed with all window locales in a single batch whenever the file count is greater than or equal to the worker thread count. This halves the task count for intermediate chunks, eliminates redundant AST and sourcemap parsing across threads, and reduces IPC and scheduling overhead.
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 refactors the i18n inliner to optimize worker thread allocation for dominant files by dynamically scaling the maximum dominant workers based on the count of dominant files. It also introduces a check to process intermediate files in a single batch when the worker pool is already saturated, reducing IPC overhead. The review feedback suggests defensively guarding against potential division-by-zero errors when calculating target workers by ensuring the dominant count is at least one.
…nt files in i18n inliner Previously, MAX_DOMINANT_WORKERS (4) was applied independently per dominant file. When multiple large bundles qualified as dominant in the same window (e.g., 3 bundles of 3 MB each), each bundle claimed up to 4 worker threads, allocating up to 12 heavy tasks simultaneously. This could saturate the entire worker pool with large AST and sourcemap remappings, starving smaller chunks and spiking peak RSS. The target worker count per dominant file now divides MAX_DOMINANT_WORKERS by the number of dominant files in the window. This preserves the existing 4-worker allocation when a single dominant file is present, while bounding aggregate dominant concurrency across the pool when multiple large bundles exist.
clydin
force-pushed
the
perf-inliner-file-surplus-sharding
branch
from
October 1, 2026 00:13
715ddea to
2afc7f5
Compare
clydin
added
the
action: review
alan-agius4
approved these changes
Oct 1, 2026
alan-agius4
added
action: merge
Member
Author
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.
When the number of uncached files in an inlining window meets or exceeds
the worker pool concurrency, the thread pool already has sufficient
file-level parallelism to keep all workers fully utilized.
Previously, all intermediate files (files between 100 KB and 70% of the
maximum file size) were sharded into batches of half their locales
regardless of the total file count. In applications with many chunks,
this doubled the number of worker tasks and forced multiple worker threads
to independently parse the same JavaScript file and decode the same source
map.
Intermediate files are now processed with all window locales in a single
batch whenever the file count is greater than or equal to the worker thread
count. This halves the task count for intermediate chunks, eliminates
redundant AST and sourcemap parsing across threads, and reduces IPC and
scheduling overhead.