metro-file-map: Spawn fewer workers for smaller workloads #1439
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.
Summary:
metro-file-map
currently spins upmaxWorkers
workers (processes, or threads ifenableWorkerThreads
) for any batch workload.maxWorkers
isos.availableParallelism
by default.When we have a warm cache or Saved State, we may only have a handful of changed files to process, and frequently create more workers than we have files.
This implements a simple heuristic factor
maxFilesPerWorker
, such that we useMath.ceil(numFiles/maxFilesPerWorker)
parallelism (where 1 "worker" means we process in-band).The default value of 100 is somewhat finger-in-air as a bunch of factors would determine the optimal value - including threads or not, which host platform, and computational cost of the haste impl and dependency extraction. We could expose this as Metro configuration in future.
Changelog:
Differential Revision: D69704168