bundleReleaseJsAndAssets slow for react-native 0.60 / node v12 combo

[mikehardy]

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

[mikehardy]

@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]

[kelset]

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?

[mikehardy]

@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)

[AndrewJack]

@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)
react-native-community/cli#485 (comment)

[mikehardy]

Thanks for the pointer I'll try that and will close this once verified

[mikehardy]

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

[palkerecsenyi]

Similar situation here. I just upgraded RN from 0.59.10 to 0.60.4 and when I run react native run-android --variant=release it quickly gets to bundleReleaseJsAndAssets but then something weird happens.

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 bundleReleaseJsAndAssets my RAM consumption gradually starts creeping up until it reaches 100% and my OS crashes and I have to force shutdown my computer.

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 run-android in verbose mode, but I get no information at all. Tried clearing all the caches I could think of and reinstalling all modules, and restarting my computer several times.

[mikehardy]

I also have a single thread bottleneck thing during the leaking portion of the problem, before it kicks off and really bundles

[palkerecsenyi]

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.

[truongngoctuan]

I downgrade to node@10 and get a fast result

[vovkasm]

Just run RN cli with --prof options, there is results if someone actually work on this, please rerun, I only publish interesting findings:

 [JavaScript]:
   ticks  total  nonlib   name
    413    0.2%    0.2%  RegExp: (ios\/.+|android\/.+|node_modules[\/\\]react[\/\\]dist[\/\\].*|website\/node_modules\/.*|heapCapture\/bundle\.js|.*\/__tests__\/.*)$
... other results irrelevant

 [C++]:
   ticks  total  nonlib   name
  211629   85.1%   85.6%  T __ZN2v87Context20BackupIncumbentScopeC2ENS_5LocalIS0_EE
  33708   13.5%   13.6%  T _fcntl$NOCANCEL
... other results irrelevant

 [Bottom up (heavy) profile]:
  Note: percentage shows a share of a particular caller in the total
  amount of its parent calls.
  Callers occupying less than 1.0% are not shown.

   ticks parent  name
  211629   85.1%  T __ZN2v87Context20BackupIncumbentScopeC2ENS_5LocalIS0_EE
  211120   99.8%    T __ZN2v87Context20BackupIncumbentScopeC2ENS_5LocalIS0_EE
  210761   99.8%      T __ZN2v87Context20BackupIncumbentScopeC2ENS_5LocalIS0_EE
  210728  100.0%        LazyCompile: ~asyncGeneratorStep /Volumes/work/yetsi/mobile/node_modules/jest-haste-map/build/index.js:191:28
  210728  100.0%          LazyCompile: ~_next /Volumes/work/yetsi/mobile/node_modules/jest-haste-map/build/index.js:212:21
  210728  100.0%            t __ZN4node10task_queueL13RunMicrotasksERKN2v820FunctionCallbackInfoINS1_5ValueEEE

This asyncGeneratorStep points to this code:

function asyncGeneratorStep(gen, resolve, reject, _next, _throw, key, arg) {
  try {
    var info = gen[key](arg);
    var value = info.value;
  } catch (error) {
    reject(error);
    return;
  }
  if (info.done) {
    resolve(value);
  } else {
    Promise.resolve(value).then(_next, _throw);
  }
}

os: macos Mojave 10.14.5
node version is: v12.8.0
To reproduce:

node --prof -- node_modules/react-native/cli.js start
# <Cmd+C>, then find a file from 100% CPU process
node --prof-process isolate-0x103dd7000-20630-v8.log > out.txt

[mikehardy]

@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.

jestjs/jest#8787 (comment)

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

[SimenB]

Jest 24.9 has been released with a fix, fwiw

[mikehardy]

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

[SimenB]

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

[mikehardy]

node v12.9 is fast again without needing the patch/workaround in jest-haste-map for anyone still following along.

[gklp]

I had trouble with node v12.15.0. Node : v12.18.0 and rn0.62.2 are very fast.