Which preset transforms still cost Hermes bytecode

Of the syntax transforms still active under the hermes-stable profile, only two move release bytecode by more than 0.1%. @babel/plugin-transform-unicode-regex expands every \p{L}-style class into kilobytes of explicit ranges and surrogate pairs. Hermes keeps each regex's source text and copies its compiled bytecode into every RegExp object it creates, so the expansion costs file size, heap and native memory. Letting Hermes compile u regexes natively removes 64–75 KB of HBC per app and makes regex-bound library code up to 17% faster and never more than 1.3% slower.

@babel/plugin-transform-async-to-generator is the second-largest size win, and it scales with how much async code an app has (about 24 B per async function). But Hermes V1's native async functions are driven by a JavaScript helper that allocates three closures per await. That makes native async slower or no faster than Babel's lowering, and heavier, in every call pattern measured except closures created per render. Preserving async is worth it for size only after Hermes optimises that helper.

Under hermes-stable in release, the 0.88 preset already preserves classes, class properties, generators, for…of, optional chaining and nullish coalescing. hermes-canary is currently identical. These syntax transforms still run on every file or every matching file, besides those that are always required (JSX, Flow, TypeScript, CommonJS modules, export default from):

Removing unicode-regex is worth 0.3–0.7% of release HBC, and async 0.1–0.2%. Everything else is within ±0.11%, and preserving private members or destructuring makes the bytecode slightly bigger. Section-level deltas confirm each change sits where the transform acts, with no knock-on operand-width changes elsewhere.

Yes for everything except let/const and async generators, which need compiler flags React Native doesn't pass today. Each feature was compiled with hermesc -O, run in the hermes VM and compared line by line with Node 26.

Native compilation makes the affected libraries smaller in memory and as fast or faster, apart from a 1% slowdown in path-to-regexp. A bundle of just the four libraries that carry such regexes is 999,805 B of HBC lowered and 894,376 B native (−10.5%). After loading them and using each once, the live JS heap is 584 KB smaller and regex bytecode in native memory is 205 KB smaller.

The mechanism is in how Hermes stores regexes. Each RegExp object keeps its source string and a private malloc'd copy of its compiled bytecode (JSRegExp::initializeBytecode), so a large expansion is paid in every live RegExp, not just in the file. highlight.js is the extreme case: it concatenates grammar regexes' .source strings and compiles the results at runtime with new RegExp. For two languages, the expanded classes cost 572 KB of heap, 204 KB of regex bytecode and 5.3–5.6 MB of peak RSS, and add about 4.5 ms to the first highlight on an M4 Pro.

Native async is up to 13% slower than Babel's lowering for awaited calls (5–13% for all but method calls) and allocates 7–41% more, in both heap layouts. The cause is how Hermes V1 implements async functions. The compiler turns an async function into an internal generator and hands it to spawnAsync, a plain JavaScript function in Hermes's internal bytecode (lib/InternalJavaScript/02-AsyncFn.js). For every await, that helper creates a fresh resolve closure, a fresh reject closure and a thunk for the next step, and always wraps the awaited value in Promise.resolve. Babel's asyncToGenerator creates its _next and _throw callbacks once per call and reuses them for every await.

Async arrows created per render go the other way. Babel lowers them to an IIFE that calls asyncToGenerator, plus an inline require of the helper, each time the arrow is created. Native creation is one closure, about half the cost, and create-plus-call is 6–7% faster. React components create many such closures (useCallback and useEffect bodies), so the net effect in a real app depends on its mix. Only the per-call cost is measured here.

Bytecode size. A test app on React Native 0.88.0-rc.4: about 5,000 modules, 9.5 MB of HBC, with React Navigation, Redux, React Query, Apollo Client, i18next, highlight.js, fuse.js, zod and three.js among its dependencies. The installed preset was patched to filter named plugins out of its returned config, so each variant differs from the baseline by exactly one plugin. Bundles: react-native bundle --platform android --dev false --minify false --unstable-transform-profile hermes-stable --reset-cache. Compilation: hermesc -emit-binary -O -output-source-map, as React Native's Android release build runs it. Block-scoping variants are compared against a baseline also compiled with -Xes6-block-scoping; the flag alone changes the baseline by 8 B. Every bundle was smoke-tested in the hermes VM, and section sizes come from hbcdump -show-section-ranges. Mattermost mobile was patched and measured the same way with its own preset.

Correctness. A feature snippet per transform, compiled with hermesc -O, run in hermes and diffed against Node 26.11.1. For u regexes, each of the 9 regexes the transform changes in the test app was run natively and in its Babel-lowered form over every code point, as four probe strings each, in both Hermes and Node.

Runtime. Small entry bundles (one per workload set) built through the same Metro pipeline and preset, with and without the plugin, then run in the hermes CLI at the same tag on an Apple M4 Pro. Two VM builds were used: the default 64-bit heap layout, and Android's layout (HERMESVM_HEAP_HV_MODE=HEAP_HV_PREFER32 with a contiguous heap: compressed pointers and boxed doubles). Timing uses Date.now(), so each sample runs at least 150 ms. The machine was shared with other work, which the interleaving and bootstrap CIs account for. Phone measurements are a follow-up.