Parallel Jetifier

[m4tt72]

Jetify files in parallel using node child_process.
Removing the console.log from the loop makes the jetifier faster

[mikehardy]

This seems cool but CI is choking on the ‘node’ version (that is ‘current’, which is v12.5 I think right now) doing the JS bundle. That seems like it shouldn’t have anything to do with this(!?), so I’ll investigate that

I will also see if I can add some sort of performance test (likely just wrapping the jetify call in time) so we can see what sort of boost this offers. I do like performance boosts but want to make sure the gain matches complexity in general - stability and longevity (which is related to a module’s ability to attract collaborators that can contribute easily) are goals of mine. I think this PR still looks reasonable from that perspective just want to make sure it really is achieving the gain that going parallel should achieve

[m4tt72]

Yes a performance test would be helpful!
On my machine, I gained +3 seconds when running the jetifier in parallel. In our project it went from 4 seconds to 800ms! not a huge performance boost but I like to squeeze every ms out of it...

[mikehardy]

3000 to 800ms is at minimum a 4x speedup, that’s motivating! I’m this close to smacking the approve button I just want to get CI working :-). Ah, CI problems.

[m4tt72]

@mikehardy the build fails probably because in the install script you are using npm instead of yarn. Try switching to yarn and see if that fixes the issue

[mikehardy]

Nah, relying on a package-manager difference to make things work is voodoo I think. npm and yarn are both capable (i use both, depending on the project, but npm in my biggest one - it’s fine).

it’s failing to bundle in RN0.60, not failing to jetify, something else is going on. I haven’t investigated yet, it’s still on the list as I work through items today. It will probably be simple, and I need to update rn-androidx-demo to RN0.60-RC3 anyway

[mikehardy]

ok, I can reproduce a couple things locally, neither of which seem to be a problem with this PR. RN0.60 + ./gradlew :app:bundleReleaseJsAndAssets is taking a really really long time right now on linux (but not macOS it seems), and I can reproduce the missing dependency to node-pre-gyp on macOS + node v12. So this PR isn't blocked but I need to fix those things separately, and I'd like the messaging changes I proposed below? What do you think?

[mikehardy]

Just about have CI all whipped into shape and re-checked this, all looks good. I’ll merge my CI tweaks then re-run this and all should be green (CI, reviews) and fast (this PR). Awesome man

[mikehardy]

Just for reference for later - the current rn-androidx-demo test suite is running at 3.4-4s forward and (because the build folder is huge) about 20s in reverse

Once I commit the CI items and merge/re-run this we'll have the competitive timings from the update. I predict ~1s forward and 5s reverse.

[mikehardy]

Well, timing was right on for scaling by CPUs with 2 CPUs, so in CI it was 2x faster - ~2s and ~10s. Nice to see it scales like that actually. This is a great addition, I can’t think of a single reason at this point why someone would object to relying on this to ease the AndroidX pain. Thanks @m4tt72