Default metro resolver slower than MetroSymlinksResolver in a monorepo about metro

[robhogan]

Hi @abejfehr - thanks for taking the time to deep-dive into this - it's always good to find out how Metro is performing in setups "in the wild" outside Meta, and particularly in this detail.

A couple of high level points -

• You've hit on two known perf/efficiency issues with the resolver here

  1. That we repeat a lot of work in typical sequences of existence checks - eg for multiple candidate extensions on the same basename (also finding the nearest package.json). This is possible to address with the addition of some fine-tuned APIs wired from TreeFS through to ResolutionContext. I plan to do this as part of the incremental resolution improvements underway at the moment (#1161), which will likely land around RN 0.74.
  2. That fast_path.relative is built to optimise for resolutions being under the project root, but is actually slower than path.relative for anything else. This is the target of #1210, which should improve the case of path under a parent or grandparent of the project root about 10x. I had this in the works already but you've reminded me to revive it :). #1209 should help too (fast_path.resolve may be the next entry down in your CPU profile?). This will be in the next Metro patch release for RN 0.73 - it'd be great to know how it works for you.

• Secondly, I am surprised @rnx-kit/metro-resolver-symlinks is faster - we don't use it and I'm not very close to its internals, but my understanding was that it augments Metro's existence checks with an IO fallback, so I'd expect it to be doing more work if anything. Since you have a like-for-like comparison with your project, might you be able to check what work Metro isn't doing as a result of using @rnx-kit/metro-resolver-symlinks? Maybe it's not using Metro's existence check for anything under a node_modules package?