-
Notifications
You must be signed in to change notification settings - Fork 613
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
bundleReleaseJsAndAssets slow for react-native 0.60 / node v12 combo #429
Comments
@kelset is this repo active? [edit - clearly maintained, just my two pet issues aren't receiving love haha - c'est la vie - I have a workaround for jest-haste-map issue at least but this performance one is still extent] |
yeah the repo is active, but it's all FB owned AFAIK. That said, try again with Hermes now (via 0.60.2), maybe it's fixed with that? |
@kelset near as I can tell this is still happening. node greater than 10 is slow (so nvm use 11 and nvm use 12 result in really slow react-native start times or bundle build times) whereas 8 and 10 are okay (so I'm currently doing nvm use 10 before I do react-native start). This may be a node issue but it is also only visible with the change from RN59 to RN60 (all versions) |
@mikehardy it's an issue with node 12.5. Downgrade to 12.4 or earlier and the issue goes away. I agree it's strange it only surfaced with RN 0.60, but it's fine with RN 0.59 facebook/react-native#25650 (comment) |
Thanks for the pointer I'll try that and will close this once verified |
I'm not saying this isn't a node issue but I wasn't able to reproduce good behavior with node 12.4 or really any node down to 8 or something at this point. I had node 11 taking something like 10GB RAM on my machine with RN60 |
Similar situation here. I just upgraded RN from 0.59.10 to 0.60.4 and when I run I have a quad-core CPU and the load on one of the four cores (seemingly random) suddenly shoots to 100% while the load on the other 3 cores stays at about 0%. I have 8gb RAM which should be able to build my simple app, but at Worked perfectly before with React Native 0.59.10. Like @mikehardy I've tried practically every Node version from 12.6.0 to 7.10.1 but that didn't seem to change anything at all. I'm using Ubuntu 19.04. I've checked my system logs and tried running |
I also have a single thread bottleneck thing during the leaking portion of the problem, before it kicks off and really bundles |
Interestingly enough, it only happens about 60% of the time. The other 40% of builds (all of them with Node 8) it builds without any significant RAM consumption above about 20% and using all 4 CPU cores, and it builds perfectly. |
I downgrade to node@10 and get a fast result |
Just run RN cli with
This asyncGeneratorStep points to this code:
os: macos Mojave 10.14.5
|
This fixes facebook/metro#429 for example.
@palkerecsenyi on macOS I see some fast builds as well, but definitely see slow ones occasionally I had inconsistent results last time I investigated, but this time I see the previous advice of "use node 12.4.0 until there is a fix" seems accurate. Additionally - (new info) based on my testing just now you might try a workaround in jest-haste-map documented here with an attached patch-package compatible patch until jest-haste-map has the workaround integrated. This is what I'm doing now. It appears the real fix will land in a future node 12.x release nodejs/node#28955 as referenced in the canonical issue for this: nodejs/node#29001 So, with two workarounds and a real fix coming, plus it's a node issue, this is definitely closed for me |
Jest 24.9 has been released with a fix, fwiw |
great news! For react-native folks I think that means that until there is a react-native released with jest-haste-map dependency updated, the way to get it is to remove packaging locks and reinstall. I'll go see over there if they need a PR for the new dependency etc Thanks so much for all the work on jest, much appreciated |
Seems like FB have to bump themselves, yeah: #432. But since it's in semver range, just refreshing ones lockfile will pull down a fixed version |
node v12.9 is fast again without needing the patch/workaround in jest-haste-map for anyone still following along. |
I had trouble with node v12.15.0. Node : v12.18.0 and rn0.62.2 are very fast. |
Hi there!
I believe I am using the most recent metro, or very near it, as this is with react-native 0.60 rc3 which has a 0.54.1 version of metro in package-lock.json after using react-native cli to do an app init using the RN0.60RC3 template
What is the current behavior?
For some reason, which this combination, it is taking a great deal more time to generate the release bundle then with any other combination of react-native 0.59 vs 0.60 and node 8, 10, 11 or "node" (currently 12.5)
I'm testing them all as part of the jetifier project in CI and this was noticeable.
I have a test script at rn-androidx-demo which use as the test suite for jetifier and the link to the build that shows the problem is here:
https://travis-ci.com/mikehardy/jetifier/jobs/212061157
You can see all an identical job but with node 11 here: https://travis-ci.com/mikehardy/jetifier/jobs/212061152 - it's 5 minutes different
The text was updated successfully, but these errors were encountered: