hermes

Hey all, I've been exploring the Hermes codebase to investigate some performance aspects of our React Native app, and I noticed a few potentially small but meaningful improvements around array fast-path handling. AI usage notice: I used AI to help identify opportunities, implement the changes, review the code, and create benchmark tests. I also manually reviewed the code and validated the benchmark results to ensure the improvements are correct and meaningful. Please let me know what I can improve/adjust to get this optimizations upstreamed into hermes! Description Resolves the in several methods by using the existing to bypass the generic per-index property protocol for ordinary s: / : move elements directly in the indexed storage under and write the new length straight to the length slot. Guarded by against , so accessors, index-like properties anywhere on the prototype chain, a read-only , and frozen/sealed arrays all fall back to the generic path. Both entry points are wrapped in to ensure the fast path allocates no handles. : copy elements straight from the source storage into the new array's storage. The check runs after argument coercion, so an array mutated by a / side effect fails the check (element count no longer matches the captured ) and falls back. / / *: hoist the fast-path check out of the loop and read each element via a new shared helper that tries the indexed storage first. This remains correct even though callbacks can mutate the array mid-iteration: a non-empty slot in the indexed storage is always a plain own data property (converting an element to an accessor deletes the indexed slot first), and re-checks bounds against the current* storage on every iteration. Holes fall back to the generic per-index read, which handles prototype-chain lookups (including Proxy prototypes installed mid-iteration). Benchmarks Apple M2, Release build, default options (HV64, no JIT — plain interpreter, matching how Hermes ships in React Native). Minimum of 3 timed runs after warmup; identical result checksums across both binaries. // improve by an order of magnitude because the fast path replaces a computed-descriptor lookup plus property get/put per element with raw indexed-storage moves. // improve less because the per-element callback invocation dominates in the interpreter. Test plan New lit test covering holes, callback-driven mutation mid-iteration (shrink/grow), accessors installed by callbacks, Proxy prototypes installed mid-iteration, frozen/sealed arrays, read-only , argument-coercion side effects in , and index-like properties on . Full on a Debug build: all tests pass. Array lit tests also run on a Debug build to force boxed doubles through the fast paths.

Original issue: https://github.com/expo/expo/issues/46519 Bug Description After upgrading to Expo 56 and as a consequence Hermes v1, RAM memory usage almost doubled in my app. I tried going back to SDK 55 and enabling the V1 Opt-In via Expo's , and the memory increase is observed there too. Steps To Reproduce Minimal reproducible example https://github.com/rodperottoni/expo-sdk-56-mem-regression Steps to reproduce I have provided an example repository with a sandbox for both Expo SDK 56 and 55. The main branch is SDK 56, and the sdk-55 branch is SDK 55. Checkout to each branch and run npm i --force + npm run compile + npm run ios. Then, open the performance monitor as soon as the app opens. Findings On SDK 56 RAM usage almost doubles in this basic example (149mb -> 266mb): This increase is more noticeable in complex apps. In my employer's production app we've jumped from ~580mb up to 1.1GB in the home page of our app. Further scenarios I tested: SDK 55 + : Increased RAM usage This scenario is in the branch of the example repo SDK 56 + : Increased RAM usage (disabling this flag seems to not do anything?) This scenario is in the branch of the example repo The Expected Behavior Memory usage to remain the same or decrease. The React Native 0.84 release notes say: Automatic performance gains: All apps will use Hermes V1 by default, bringing improved execution speed and reduced memory usage.

Summary: Use the platform path-list separator for shermes CC include/library paths on Windows. Split generated CC path lists with . Add a Windows regression test for drive-letter paths in verbose native compilation output. Test Plan: with Fixes #1994