fix: avoid reallocating views on RCTDevLoadingView showMessage calls #2762
+27
−14
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.
This PR is equivalent to the upstream PR facebook#54608. Actually, the upstream PR is a little different, as I had to handle the new
self->_dismissButtonthat was addeed in facebook#54445 as well. When I came to handleself->_dismissButton, I took the opportunity to optimise theNSConstraintLayoutbit while I was there, so be ready for both of those changes in[email protected]!Summary:
As this PR regards the dev loading view, this issue of course affects only debug builds. The issue is that, each time a Metro progress update triggers the
showMessage:withColor:withBackgroundColor:method onRCTDevLoadingView, we end up allocating a newUIWindow(iOS) orNSWindow(macOS), rather than reusing the existing window stored onself->_windowfrom any previous progress updates. These unnecessary allocations are particularly expensive on macOS, as I show below.Demo of the issue on macOS
On
react-native-macos, the impact of this issue is dramatic (so much so that the Microsoft Office team disableRCTDevLoadingViewin their Mac app). On the first connection to Metro (as first-time connections can produce nearly 100 progress updates), we end up allocating nearly 100NSWindows. AllocatingNSWindows is so expensive that it blocks the UI thread and adds 30 seconds to app launch (see 00:40 -> 01:15 of the below video clip).What's more, as we can see in the view debugger, these
NSWindows never get released, so they remain in the view graph and just leak memory (see 01:15 -> 01:30 of the below video clip).(This clip is from 1:15:00 of a livestream where I dug into this problem – sorry for the poor quality clips, that's the best the servers allow me to download)
mwe_clip.mp4
Solution
Each of these views (the window, the container, and the label) need only be allocated once. Thereafter, they can be modified. This PR adds conditionals to lazily-allocate them, and reorders them in order of dependency (e.g. the label is the most nested, so needs to be handled first).
Changelog:
[MACOS] [FIXED] - Avoid reallocating views on RCTDevLoadingView progress updates
Test Plan:
I am unable to run
RNTesteron the latest commit of themainbranch; I've tried five different versions of Ruby, but thebundle installalways fails. If someone could please guide me how to get RNTester, Ruby, and Bundler happy, I'd be happy to use that app to test it onmain.So my testing so far has been based on patching an existing
[email protected]app live on stream. This version of React Native macOS has the exact same bug as currentmain, so it should be representative.