Learn Hermes JS Engine - Performance Optimization Strategies

#Introduction

Episode 14 structured the architecture: clear boundaries, modularized bundles, and isolated foreign code. Now we talk about speed. Hermes isn't V8 — it's interpreter-based, without JIT, and very sensitive to the shape of the code you write. The good news: the rules are clear and learnable.

The roadmap for episode 15: the JavaScript code patterns most friendly to Hermes, avoiding hot-path allocation and the cost of runtime polymorphism, then Hermes-specific profiling hints for finding bottlenecks.

#How Hermes Executes Code

Hermes executes bytecode with an interpreter. Without JIT, code isn't warmed up and optimized like in V8 — every execution goes through the same path. The consequences:

• Object shape matters a lot: Hermes optimizes property access based on consistent object shapes.
• Property names are better than dynamic keys: stable name lookups can be optimized; dynamic lookups can't.
• Frequently called functions still dispatch per call: there's no JIT-style automatic inlining.

The best pattern for Hermes is code whose shape is predictable. This thought runs through every tip in this episode.

One interesting consequence: optimizations that win in V8 don't necessarily show up in Hermes, and vice versa. Micro-benchmarks that dominate on a JIT engine can go flat on an interpreter. So always test code patterns on the engine you actually use — resist the temptation to copy performance tips from other engines without verifying them yourself.

#Interpreter-Friendly Code Patterns

Consistency is everything. When you create objects with the same properties every time, Hermes can bind property access quickly. A good example:

shape-konsisten.js

function buildItem(name, price) {
  return { name, price, sold: false };
}
 
const items = [
  buildItem("kopi", 15),
  buildItem("teh", 10),
];

All elements have an identical shape. Compare that with creating objects with different keys or adding properties later — every shape change forces the interpreter into more expensive lookups. If possible, finalize objects as soon as possible: define all properties in the constructor, don't add them afterward.

#Avoiding Hot-Path Allocation

Allocation is expensive — not because of creation itself, but because it presses on the GC. Code running millions of times per second, for example a render loop, list transforms, or animations, shouldn't create throwaway temporary objects. A common leak:

hindari-alokasi-loop.js

function render(rows) {
  const out = [];
  for (const row of rows) {
    out.push({ text: row.label, height: row.h + 2 });
  }
  return out;
}

Every iteration creates a new object that will become garbage. For hot paths, consider reusing a buffer or existing structures:

reuse-buffer.js

function renderInto(rows, out) {
  out.length = 0;
  for (const row of rows) {
    out.push(row.label + "|" + (row.h + 2));
  }
  return out;
}

Using a reset array trades allocation for in-place updates. The result: a calmer GC and no more frame-rate jank. The same pattern applies to string concatenation inside loops — avoid building long strings piece by piece in every iteration.

#Avoiding the Cost of Runtime Polymorphism

Polymorphism here isn't about classes, but about objects being called with different shapes. When the same function is called with differently shaped objects, Hermes can't optimize its property access. This is called a megamorphic call site, and its cost is real:

kunci-dinamis-berbahaya.js

function read(obj, key) {
  return obj[key]; // the object shape can't be predicted
}

If key always comes from the same small set, register the property names explicitly and use simple dispatch. Related points: don't mix two object shapes inside a single array, and avoid changing property types — for example from number to string — on objects used repeatedly.

As an illustration, two different shapes can appear just because one object is built through one construction pattern and another through a slightly different one. That kind of consistency is often what separates tidy code from messy code in terms of performance, even at the micro level.

#Leveraging Hermes-Specific Profiling Hints

Hermes provides a window into itself through runtime properties. Call getRuntimeProperties() to see statistics like heap size and GC pause time:

runtime-properties.js

const props = HermesInternal.getRuntimeProperties();
console.log(props["kGCHeapSize"]);
console.log(props["kGCTotalPauseTime"]);

For deeper analysis, connect Hermes to Chrome DevTools, as discussed in episode 7, and observe: CPU profiles to find the functions absorbing the most time, heap snapshots to measure allocation, and animation flame charts to detect jank. Remember the healthy cycle: measure first, hypothesize the cause, fix, then measure again. Never optimize based on guesswork.

#Conclusion

Hermes performance isn't a mystery — it's an honest interpreter: give it code with a consistent shape, avoid allocations in hot paths, and stay away from polymorphism, and the interpreter will serve you well. Use runtime statistics and DevTools to validate every optimization decision.

The essentials to take home:

• The Hermes interpreter loves certainty: consistent object shapes are the key to fast access.
• Define all properties in the constructor; don't add properties afterward.
• Hot paths must not allocate temporary objects; reusing buffers is better.
• Megamorphic call sites are expensive; avoid dynamic keys and mixed object shapes.
• Measure with getRuntimeProperties() and DevTools before and after optimizing.

In episode 16 we open the compiler's hood: Hermes Compiler Internals — the hermesc pipeline from frontend, IR, optimizer, to code generation, how bytecode is produced and serialized, plus custom build flags and optimization tiers. See you there!