Performance regression between 0.73.9 and 0.76.8 about metro

[robhogan]

Hi @asherLZR - thanks for the report. The specific detail of a regression between those versions (and how clear your numbers make that) is new information for me, so I'm happy to investigate this as a separate issue until we've pinned down the point of regression. Indeed the fact that the regression is similar with and without cache suggests a main thread issue, and most of that is (or should be) module resolution.

We didn't knowingly regress while introducing symlink support (in fact we were pretty careful trying not to) but obviously something has slipped between those versions that we're not aware of.

I will investigate further and check next week to see if we can upgrade to the latest metro despite being currently tied to RN72 for now.

We don't normally recommend this (we don't guarantee new Metro supports older RN, especially around things like downlevelling for Hermes) but for the sake of experiment it can be done with eg Yarn resolutions, taking care around the breaking changes in Metro's release notes. For Metro 0.80 with RN 0.72 I'd recommend using the RN 0.73-style metro.config.js, extending @react-native/[email protected]. I think that should work.

In the mean time I'm going to try to reproduce something with an artificial project of a similar structure - if I can't do that I'd love your help bisecting this down to at least a particular Metro release, if you're willing, or if (NDA) access to your repo is possible I'd be happy to take a look. I feel like this is pretty important to get to the bottom of!

Update
There's a detectable resolution perf regression on acbfe63 between 0.74.1 and 0.75.0 - I'd be interested to know whether that reproduces on your repo. Investigating further...

[asherLZR]

I would be happy to assist with the bisect of this for now and we can explore further options if need be. My test method so far has been to run once with --reset-cache then 3 subsequent times without.

I've tried to keep things constant in the environment by not doing memory/cpu intensive tasks but there will be some uncertainty. Despite this, there is indisputable change between 0.75.0 and 0.76.8. Where possible, I will continue with narrowing down the versions this week.

• Baseline 0.73.9
• 0.74.1 no change relative to baseline
• 0.75.0 +23% relative to baseline
• 0.76.8 +80% relative to baseline

[robhogan]

Ouch, that looks like two regressions.

The first one (in 0.75.0) is due to an increase in path.resolve and path.relative calls, which are maybe-surprisingly expensive. We're working on a fix for that.

The second is new to me - that'll take some more bisection. Hopefully it's reproducible in the sample projects I have.

Thanks again for your help with this.

[asherLZR]

Thanks for the helpful insight. I've managed to run a new set of tests. The good news is that between 0.76.2 and 0.80.6 there appears to be little regression (on par with 0.76.8 as described in the original post).

My results tell me that something introduced between 0.76.1 and 0.76.2 caused the further slow down of ~20%.