refactor: Tweak metro-file-map's Node crawler hot-path#1677
Open
kitten wants to merge 8 commits into
Open
Conversation
robhogan
reviewed
Apr 9, 2026
59a90f5 to
416901a
Compare
ea59e3f to
c46237d
Compare
A previous implementation kept a `visited` set in the Node crawler. Instead, we can also deduplicate and remove overlapping roots (directories within other roots) in the `FileMap` preemptively for all crawlers to prevent duplicate crawls.
c46237d to
c1cea5c
Compare
kitten
added a commit
to expo/expo
that referenced
this pull request
May 5, 2026
meta-codesync Bot
pushed a commit
that referenced
this pull request
May 11, 2026
…ceNodeFilesystemAPI` flag) (#1693) Summary: This is a proposal to drop the native find binary crawler code path entirely. We've recently dropped the native find binary crawler in Expo, which was accidentally activated in some cases. We discovered (which is particularly obvious on large projects/repos and `expo/expo` itself) that it's consistently much slower than the Node FS crawler. To get into the "correct" preference and use the Node crawler, we're currently forcing `useWatchman: null`, which then defaults to use watchman, if it's installed, but falls back to `forceNodeFilesystemAPI: true`. This is outside of what the types specify as valid, but is the cleanest way to disable the native find binary crawling. This crawler basically just adds overhead over the Node.js implementation and is consistently slower, and less efficient, while the Node crawler is pretty optimised already (and has very low overhead once #1677 is merged) The timings of the native find binary crawler in `expo/expo` was also observed to scale with the size of this repo, compared to a minimal reproduction, so the overhead isn't just limited to the child process call and result parsing. Changelog: [Internal] Drop native find binary crawler and remove `forceNodeFilesystemAPI` flag Pull Request resolved: #1693 Test Plan: - Existing tests should pass - Quick generated script to play around with and assess the crawlers' comparative performance: kitten@74dffd4 Reviewed By: huntie Differential Revision: D101985455 Pulled By: robhogan fbshipit-source-id: efe2ab02fc5c0edac4d68f037db57c635fef8e50
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.
Summary
When a larger amount of paths are being crawled, the Node crawler becomes a hot-path and minor tweaks can have a larger impact on startup time, than previously anticipated (at least for Expo projects)
absoluteToNormalcalls (medium impact)forEachcalls for for-of (formatting only; virtually no impact)I don't currently have benchmarks for the above, and it's derived from running
apps/router-e2eonexpo/expo's main branch and modifyingmetro-file-map's Node crawler.Changelog: [Internal] Refactor performance sensitive Node crawler hot path in metro-file-map
Test plan