Native destructuring on Hermes V1

The change is a net win for typical apps. The speedup comes from two Babel helpers that idiomatic code calls constantly: slicedToArray (every const [x, setX] = useState()) and objectWithoutProperties (every const {style, ...rest} = props in a component body, including React Native's own components). Native destructuring makes those 45–55% and about 80% faster per call. The gain is small in wall-clock terms because an app spends little of its time destructuring: the test app calls these helpers about 1,400 times to first frame, worth 0.7–1.2 ms.

The tradeoffs are real but narrow. Hermes has no equivalent of several Babel special cases, so a handful of array patterns get several times slower, and every array pattern costs about 31 bytes more bytecode. One configuration also breaks: dev builds with enableBabelRuntime: false crash in the preset's regenerator transform.

The test app is a small idiomatic React Native app: React Navigation bottom tabs, a FlatList feed of post cards (avatars, buttons, tags, action bars), and a settings screen, written with the usual hooks, props destructuring and object rest. A counting build wrapped the three Babel destructuring helpers to see how often real UI code hits them.

• Builds. One RN 0.88.0-rc.4 template app, built for release on both platforms (Hermes V1, release VM, no JIT, confirmed at runtime from HermesInternal). Variant A is the current default; variant B sets unstable_preserveDestructuring, which is what the PR makes the default.
• Micro suite. Each case is written once and compiled into the same bundle twice: verbatim, and pre-lowered with the preset's exact plugin options (transform-destructuring with useBuiltIns, helpers via transform-runtime). Both run in one process, alternating order per sample, each sample about 40 ms, 15 samples × 3 launches. Iteration counts are identical for both forms and results are compared for equality.
• Control. The same suite in a variant A build, where both copies end up lowered, shows 0.46% (A16) and 0.69% (iPhone) mean absolute difference. Seven parameter-destructuring cases, unaffected by the transform, sit within ±0.5% in every run.
• App A/B. Four interleaved rounds per device (ABBA order), each with 10 cold launches and 2 render runs per variant. Render runs time 60 theme changes and 60 FlatList remounts after 10 warm-up iterations. Startup marks come from Metro's __BUNDLE_START_TIME__ and performance.now() at first commit and the following frame.
• Transform profile. RN 0.88.0-rc.4's bundle command still defaults --unstable-transform-profile to default (main switched to hermes-stable in #57911), and neither the Xcode nor the Gradle bundling step overrides it. So the on-device builds here lower classes in both variants. The destructuring toggle is independent of the profile and the micro suite contains no classes; the bundle-size rows for the template and RNTester use hermes-stable.
• Helper resolution. App code lowered by the preset imports Babel's CommonJS helpers. With Metro's inline requires, each lowered array destructure pays a require() call inside slicedToArray, which makes those helpers about 55% slower than their ESM copies (helpers/esm/*, resolved when code uses import). The lowered side of every comparison here uses the CommonJS helpers apps really get.

• Keep @babel/plugin-transform-destructuring on whenever the preset adds the regenerator transform, or the dev + enableBabelRuntime: false configuration breaks.
• Optionally keep Babel's array-literal special case with a tiny plugin, or ask Hermes to fold [a, b] = [x, y] and array-typed rest parameters in IRGen; the rest of the transform can go.
• The bytecode cost is concentrated in array patterns; worth a look from the Hermes side (fast path for two- and three-element arrays) rather than a reason to keep the transform.

Hermes has a hidden compiler flag, -Xenable-fast-destructure (also implied by -Xenable-fast-noncompliant), described as "UNSUPPORTED: Enable a faster, but non-compliant, array destructuring". It was not benchmarked on device: its effect is narrow enough to be read from the compiler, and it does not touch any of the tradeoffs above.

What it changes. In native array destructuring, Hermes wraps each store to a target, and each default initialiser, in a try/catch that closes the iterator if that step throws, as the spec requires. The flag drops those wrappers. Stores to plain local bindings can't throw, so a pattern like const [value, setValue] = useState() never had one and compiles identically with or without the flag. Only array patterns with defaults ([a = f()]), nested patterns and member-expression targets ([obj.a, b] = pair) change.

Expected speed. No measurable change. Hermes implements try/catch with exception tables, so a try region costs nothing while nothing throws; the flag removes bytecode and handler entries, not work on the normal path. The array-pattern regressions above come from walking the iterator protocol where Babel indexes directly, which the flag leaves as it is.

Size. The bundles with native destructuring, compiled again with the flag by RN 0.88's hermesc:

That recovers roughly a tenth of the 0.1–0.5% that native destructuring adds to bytecode.

Compatibility. For arrays nothing observable changes, because array iterators have no return(). For generators and custom iterables it does: if a default initialiser or a target throws mid-pattern, return() is skipped, so a generator's finally cleanup does not run.

Recommendation. Don't adopt it alongside this change. It would mean passing an unsupported, non-compliant flag in both the Xcode and Gradle bundling steps for a 0.01–0.05% bytecode saving and no expected runtime gain.

Almost all of it is the code Hermes emits inline for array destructuring, and most of that is per-element bookkeeping around the iterator rather than the iterator operations themselves. Object patterns compile to the same bytecode as Babel's output, and object rest is smaller.

Opcode-level differences between the two builds, release bytecode for Android:

In Mattermost about 14 KB of object-literal instructions also switched between their long and short encodings as buffer offsets shifted; that is layout churn, not a destructuring cost. Strings, literal buffers and function counts are otherwise roughly neutral.

For var [x, y] = a, Hermes emits:

Each element pays for a done check, a conditional default to undefined, a branch that skips later next() calls, and register copies, about 19 bytes against a 4-byte IteratorNext. Mov alone is 38% of the added bytes.

Ways Hermes could claim it back

• Let iterator instructions handle exhaustion. Hermes already marks a finished iterator by setting its register to undefined. An IteratorNext variant that yields undefined from a finished iterator, and an IteratorClose that does nothing for one, would let the compiler drop the per-element check, branch and default: one 4-byte instruction per element. Estimated from the opcode counts, RNTester would add about 5 KB against the 13.8 KB removed, so native destructuring would come out smaller than Babel's output, with fewer branches on the normal path too. This needs a new opcode or a bytecode version bump.
• A fused array-destructure instruction. Something like DestructureArray dst, count, src could fill consecutive registers when the source is an array with the default iterator, which IteratorBegin already detects, and fall back to the generic sequence otherwise: about 5 bytes per pattern plus one per element.
• Fewer register copies. Many Movs look like artefacts of lowering the iterator and done flag through stack slots; better coalescing after destructuring could remove some without new instructions.
• Babel's special cases, at compile time. When the right-hand side is an array literal, or a rest parameter that is known to be an array, Hermes could assign elements directly as Babel does. That would fix both the size and the 2–11× slowdowns above.

The per-element saving and the RNTester estimate are derived from opcode counts and encodings, not from a prototype. Meta's increase scales with its number of array patterns and its own Babel configuration.