Improve Fast Refresh responsiveness when watching a large number of files #913
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:
Following D40829941 (7191173), where we changed the output of
metro-file-map
'sbuild()
to return "live" references to the file system and the Haste module map (rather than snapshots), we no longer require further snapshots to be emitted as part of a change event payload. In fact,ChangeEvent['snapshotFS']
andChangeEvent['moduleMap']
are currently only referenced in test code.Removing them means we don't have to copy potentially large data structures on each emitted change.
With ~300k files and ~150k Haste map entries, this amounts to ~200ms more responsive fast refresh - in general this boost will be proportional to the total number of files+Haste modules watched.
After this, a
HasteFS
instance is only constructed once, on Metro startup. That clears the way for an alternative (more expensive to initialise) implementation capable of performing lookups through symlinks.Changelog: [Performance] Improve Fast Refresh responsiveness when watching a large number of files.
Reviewed By: motiz88
Differential Revision: D42303139