Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

metro-file-map: Spawn fewer workers for smaller workloads #1439

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

robhogan
Copy link
Contributor

Summary:
metro-file-map currently spins up maxWorkers workers (processes, or threads if enableWorkerThreads) for any batch workload. maxWorkers is os.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 use Math.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:

  • [Performance] Don't start an excessive number of workers for hashing files during startup.

Differential Revision: D69704168

Summary:
This error message isn't accurate since Metro added symlink support, and doesn't suggest the most likely cause, which is that the requested file isn't watched.

Metro's resolver should never resolve an unwatched file, but custom resolvers (like `rnx-kit`'s) might.

Changelog: Internal

Reviewed By: vzaidman

Differential Revision: D69397742
Summary:
`metro-file-map` currently spins up `maxWorkers` workers (processes, or threads if `enableWorkerThreads`) for any batch workload. `maxWorkers` is `os.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 use `Math.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:
 - **[Performance]** Don't start an excessive number of workers for hashing files during startup.

Differential Revision: D69704168
@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Feb 16, 2025
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D69704168

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. fb-exported
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants