Chasing a Phantom Jump: How We Made Pingo's Animations Smooth on Low-End Android

Why a Correct Animation Can Still Look Like It Jumps

The Dominant Cost: How Skia Composites on Android

Bisecting at Machine Speed

The Second Cost: A Redraw That Should Not Exist

A Smaller, Self-Inflicted Cost: React Churn

The Fixes, in Order of Impact

TextureView to SurfaceView

Killing the Self-Dirtying Redraw Loop

Keeping React Work Off the Canvas

Removing Per Frame Allocations

Real World Results

See it on a real device

Final Words

What's Next

Building a Video Call App with Filters

The Backend

A Basic Video Call

How LiveKit Injects Frames

Taking Over the Camera with VisionCamera

Where the Source Comes From

Matching the Format WebRTC Expects

The Complete Path

Adding Filters

Background Blur

Color and Photo Backgrounds

Center Stage

Air Draw

Performance

Final Thoughts

Four Years of React Native Quick Crypto: From Wallets to Node Parity

A library born in the wallet boom

Szymon: the OpenSSL plumbing

Oscar: ciphers and signing

How I got pulled in

Nitro: rewriting the layer underneath

What runs where: sync by default, threaded when it's heavy

From "works for wallets" to Node parity

Post-quantum, on a phone

Six phases of security audit

How fast is "fast," in 2026?

Adoption

What it looks like today

Appendix: full benchmark results

The Go-To Guide for Understanding Keyboards in React Native (Part 1)

How keyboards actually work on iOS and Android

iOS: scheduled animation, two snapshots

Android: per-frame events and the inset model

`Keyboard.addListener`: the JS surface

So why does cross-platform feel hard?

Why `KeyboardAvoidingView` from React Native is great on iOS and bad on Android?

The drop-in replacement from `react-native-keyboard-controller`

When `KeyboardAvoidingView` is not enough - `KeyboardAwareScrollView`

The problems `KeyboardAvoidingView` cannot solve

Why focused-input tracking matters

A typical usage

The hidden player - `KeyboardStickyView`

The problem

The fix: translate, do not resize

Usage

When to pick which

Wrapping up

Choosing the wrong data representation in a JSI module can make your code **30x slower** — with no algorithmic mistake, just the wrong shape.

In the [first part](/make-jsi-run-faster) we covered HostFunction vs HostObject, NativeState, and stack allocation. This post goes one level deeper: how data crosses from C++ to JS, how the API contract between layers is designed, and how strings are built on the native side. Each section has benchmarks.

<Callout icon="📊">
All benchmarks were run in a release build with Hermes.
Each test executes the function 100,000 times.
Results are averaged across 5 runs.
</Callout>

## Data shape: from objects to raw memory

Native code often needs to return data back to JavaScript. There are several ways to do that, and the difference between a slow representation and a fast one can be significant.

Imagine a function that runs for every camera frame, detects something in the image, and returns a list of points. For example, these could be face landmarks that we later render on the JS side.

```cpp
struct Point {
  int32_t x, y;
};
```

Since there can be many points, we will represent them as a vector:

```cpp
std::vector<Point> points;
```

Let's write a small helper that generates test points:

```cpp
constexpr size_t pointsCount = 50;

auto createPoints = []() -> std::vector<Point> {
  std::vector<Point> points;
  points.reserve(pointsCount);

  for (int i = 0; i < pointsCount; ++i) {
    int v = i * 2;
    points.emplace_back(v, v + 1);
  }
  return points;
};
```

Now we need to return this data to JS. The first solution that usually comes to mind is an array of objects, so JS receives `Array<{x:number,y:number}>`.

### Array of Objects

```cpp
Function process = Function::createFromHostFunction(..., [](...) {
  std::vector<Point> points = createPoints();
  auto size = points.size();

  jsi::Array jsPoints(rt, size);

  int index = 0;
  for (auto& [x, y]: points) {
    jsi::Object obj(rt);

    obj.setProperty(rt, "x", x);
    obj.setProperty(rt, "y", y);

    jsPoints.setValueAtIndex(rt, index, std::move(obj));

    index++;
  }

  return jsPoints;
});
```

This looks nice. On the JS side, the data is very easy to work with:

```jsx
points.forEach(({x, y}) => {
  // Do something
})
```

Let's benchmark this code.

**Benchmark (100,000 calls)**

```cpp
Array of Objects: 1036.50ms
```

This is not optimal. Every `jsi::Object` is a separate allocation on the JS heap, and every `setProperty` call crosses into the JSI layer. With 50 points, that means 100 property writes plus 50 object allocations that the GC has to track. Let's remove that overhead.

<Callout icon="🧠">
The main cost here is not the loop itself, but crossing the JSI boundary multiple times and allocating many small JS objects that the GC has to track.
</Callout>

### Flat Array

Instead of creating objects, we can flatten the array.

The data will look like this:

```cpp
[x, y, x, y, x, y, ...]
```

To produce this shape, we only need to change the JSI function a little:

```cpp
std::vector<Point> points = createPoints();
auto size = points.size();

jsi::Array jsPoints(rt, size * 2);

int index = 0;
for (auto& [x, y]: points) {
  jsPoints.setValueAtIndex(rt, index, x);
  jsPoints.setValueAtIndex(rt, index + 1, y);
  index += 2;
}

return jsPoints;
```

On the JS side, access becomes slightly less convenient:

```jsx
for (let i = 0; i < points.length / 2; i++) {
  const index = i * 2;

  const x = points[index];
  const y = points[index + 1];
}
```

Let's see how much faster this is:

**Benchmark (100,000 calls)**

```cpp
Flat Array: 311.78ms // 3.3x Faster
```

That is already a strong result: the function became **3.3x** faster.
Since we are only returning numbers, we can push this further.

### ArrayBuffer

We can avoid creating a JS array and JS objects altogether. Instead of building a JavaScript structure element by element from C++, we hand JavaScript a **direct pointer to our native memory**. No per-element JSI calls. No GC pressure from individual values. No second allocation. Just one contiguous block of bytes that both runtimes share.

<Callout icon="⚡">
JSI's `MutableBuffer` is a C++ interface that lets native code own the underlying memory. The resulting `ArrayBuffer` on the JS side is just a view into that same allocation — the data never gets copied at all.
</Callout>

### The MutableBuffer contract

`jsi::MutableBuffer` is a pure virtual base class with two methods:

```cpp
class MutableBuffer {
public:
  virtual size_t size() const = 0;
  virtual uint8_t* data() = 0;
};
```

You subclass it, back it with any storage you want — a `std::vector`, a `malloc`, a memory-mapped file — and JSI exposes that memory as an `ArrayBuffer` in JavaScript with zero intermediate copies.

Here is our implementation:

```cpp
class PointsBuffer : public jsi::MutableBuffer {
  std::vector<Point> points_;
public:
  explicit PointsBuffer(std::vector<Point>&& points)
    : points_(std::move(points)) {}

  size_t size() const override {
    return points_.size() * sizeof(Point);
  }

  uint8_t* data() override {
    return reinterpret_cast<uint8_t*>(points_.data());
  }
};
```

The key detail: `points_` is **moved in**, not copied. The vector allocates once during `createPoints()`. `data()` returns that same pointer — no second allocation ever happens.

The JSI function itself becomes trivial:

```cpp
auto process = Function::createFromHostFunction(..., [](...) {
  std::vector<Point> points = createPoints();
  auto buffer = std::make_shared<PointsBuffer>(std::move(points));
  return jsi::ArrayBuffer(rt, std::move(buffer));
});
```

### Reading it on the JS side

Our `Point` struct is two `int32_t` fields — 8 bytes per point, packed tightly. We read it with `Int32Array`, which is a typed view into the raw bytes with no additional boxing or copying:

```js
const buffer = process(); // returns ArrayBuffer
const view = new Int32Array(buffer);

for (let i = 0; i < view.length / 2; i++) {
  const x = view[i * 2];
  const y = view[i * 2 + 1];
}
```

<Callout icon="🧠">
The typed array type must match the C++ layout exactly. `int32_t` → `Int32Array`, `float` → `Float32Array`, `double` → `Float64Array`. If your struct has padding or mixed types, account for it in the byte offsets or use a `DataView` for precision.
</Callout>

### Benchmark (100,000 calls)

```
ArrayBuffer: 34.81ms  // 29x faster than Array of Objects
```

That is a huge improvement: **~30x** faster than `Array<Object>` and **~9x** faster than `Flat Array`.

<Callout icon="🚀">
In workloads like camera processing, this kind of representation change can be the difference between staying within the frame budget and dropping frames.
</Callout>

### Data shape summary
The difference between approaches is not incremental — it is an order of magnitude.

<PerformanceBars items={[{label:"Array of Objects",time:1036.5,color:"#ff353a"},{label:"Flat Array",time:311.78,color:"#aaa51a"},{label:"ArrayBuffer",time:34.81,color:"#1ecb21"}]} />

---

## API shape: strings vs numbers

Now let's talk about passing parameters into a native function and branching based on those parameters.

Suppose we have a function that accepts a `type` parameter representing a data format.
I have seen code shaped like this in a real production repository. The example below is simplified and slightly changed for clarity, but the idea is the same:

```cpp
enum class NativeType {
  NONE = 0,
  ST_1 = 101,
  ST_2 = 151,
  ST_3 = 180,
  ST_4 = 190,
  ST_5 = 221,
  ST_6 = 230,
  ST_7 = 252
};

...
const std::string type = args[0].asString(rt).utf8(rt);

auto code = NativeType::NONE;

if (type == "uint8") {
  code = NativeType::ST_1;
} else if (type == "uint16") {
  code = NativeType::ST_2;
} else if (type == "int8") {
  code = NativeType::ST_3;
} else if (type == "int16") {
  code = NativeType::ST_4;
} else if (type == "int32") {
  code = NativeType::ST_5;
} else if (type == "float32") {
  code = NativeType::ST_6;
} else if (type == "float64") {
  code = NativeType::ST_7;
}
...
```

This function receives `type` as a JS string and maps it to a native numeric type on the JSI side. This approach has two sources of overhead: `asString(rt).utf8(rt)` allocates on the heap and copies data through the JSI boundary, and the following string comparisons add more work on every call.

Let's benchmark it:

**Benchmark (100,000 calls)**

```cpp
Branch string: 12.88ms
```

The gains here are modest in absolute terms, but the pattern matters on paths called thousands of times per second — for example, processing a stream of sensor events or a high-frequency callback from a native module.

Looking at the code, we can pass a numeric value from JS to JSI and keep the same behavior.

JS:

```jsx
enum Types {
  uint8 = 0,
  uint16 = 1,
  int8 = 2,
  int16 = 3,
  int32 = 4,
  float32 = 5,
  float64 = 6,
}
```

JSI:

```cpp
...
const int type = args[0].asNumber();
auto code = NativeType::NONE;

switch (type) {
case 0:
  code = NativeType::ST_1;
  break;
case 1:
  code = NativeType::ST_2;
  break;
case 2:
  code = NativeType::ST_3;
  break;
case 3:
  code = NativeType::ST_4;
  break;
case 4:
  code = NativeType::ST_5;
  break;
case 5:
  code = NativeType::ST_6;
  break;
case 6:
  code = NativeType::ST_7;
  break;
default:
  break;
}
...
```

The code is similar, but it is already more efficient: we pass a number instead of a string, and there are no string comparisons.

**Benchmark (100,000 calls)**

```cpp
switch int: 9.13ms
```

The result is a little better. But if we look at the `switch`, it is effectively an indexed lookup. We can make the code cleaner and remove the branch entirely:

```cpp
static std::array<NativeType, 7> codes{
  NativeType::ST_1,
  NativeType::ST_2,
  NativeType::ST_3,
  NativeType::ST_4,
  NativeType::ST_5,
  NativeType::ST_6,
  NativeType::ST_7
};
...

const int type = args[0].asNumber();
const NativeType code = codes[type];
```

In this example, we removed the `if-else` chain and the `switch`, created a `std::array`, and read the value by index.

<Callout icon="💡">
This assumes that `type` is always a valid index. In production code, validate the input before indexing into the array. `assert(type >= 0 && type < codes.size())` is useful in debug builds, but release builds should still guard against invalid JS input if it can happen.
</Callout>

<Callout icon="💡">
You could pass the final native value directly from JS and avoid this mapping.

In practice, the native side often needs to initialize multiple internal values based on the input (enums, modes, flags, etc). Using an index + lookup table keeps the JS API minimal while resolving everything in one place on the native side.
</Callout>

**Benchmark (100,000 calls)**

```cpp
lookup table: 8.67ms
```

This version is the fastest and the cleanest.

<Callout icon="💡">
If your API is called frequently, even small costs like string conversion (`asString(rt).utf8(rt)`) become visible. Prefer numeric contracts between JS and native.
</Callout>

### API shape summary
If your branches only initialize values based on a type passed from JS, consider using `switch + int` or a lookup table instead of strings.
<PerformanceBars items={[{label:"if else + string",time:12.88,color:"#ff353a"},{label:"switch number",time:9.13,color:"#aaa51a"},{label:"lookup table",time:8.67,color:"#1ecb21"}]} />

---

## String building: convenience vs performance

Suppose we are writing a function that requests data from the GitHub REST API. We need to fetch the latest release tag for a repository, so we need two parameters: `USER_NAME` and `REPO_NAME`.

The URL looks like this: `/repos/{USER_NAME}/{REPO_NAME}/releases/latest`

Now suppose we store many `USER_NAME`/`REPO_NAME` pairs and make requests for several repositories. We need to build the URL dynamically based on the input.

Let's look at a few options. The first and most convenient one is `std::format`.

### std::format

```cpp
auto url = std::format("/repos/{}/{}/releases/latest", user_name, repo_name);
```

The benchmark shows this result:

**Benchmark (100,000 calls)**

```cpp
std::format: 21.35ms
```

This version is the most convenient, but it is not ideal on a hot path. `std::format` has to process the format string, perform type dispatch, and build the result through formatting machinery that is heavier than simple concatenation. For code that runs very frequently, a more explicit approach can be faster.

### std::string concatenation

```cpp
std::string url;
url.reserve(7 + user_name.size() + 1 + repo_name.size() + 16);

url += "/repos/";
url += user_name;
url += '/';
url += repo_name;
url += "/releases/latest";
```

This code is a little more verbose. Let's look at the benchmark:

**Benchmark (100,000 calls)**

```cpp
std::string concatenation: 12.38ms
```

That is better: this version is **1.7x** faster.

There is one more implementation worth looking at.

### Char buffer

```cpp
...
// Buffer must be large enough to hold the full URL + null terminator.
// Validate total length in production to avoid overflow.
char buffer[128];

char* ptr = buffer;

auto user_name_size = user_name.size();
auto repo_name_size = repo_name.size();

std::memcpy(ptr, "/repos/", 7);
ptr += 7;
std::memcpy(ptr, user_name.data(), user_name_size);
ptr += user_name_size;
std::memcpy(ptr, "/", 1);
ptr += 1;
std::memcpy(ptr, repo_name.data(), repo_name_size);
ptr += repo_name_size;
std::memcpy(ptr, "/releases/latest", 16);
ptr += 16;
*ptr = '\0';
...
```

In this version, we allocate a fixed-size buffer on the stack, copy each part of the URL into it, move the pointer after each copy, and finish with `\0` to mark the end of the string.

<Callout icon="⚠️">
This approach is only safe when the maximum input size is known and validated. If `user_name` or `repo_name` can be arbitrary, check the total length before copying or use a bounded API. The benchmark is meant to show the cost of string construction when the size is controlled.
</Callout>

Let's benchmark this implementation:

**Benchmark (100,000 calls)**

```cpp
char buffer: 7.78ms
```

This version is **1.6x** faster than `std::string` concatenation and **2.7x** faster than `std::format`.

<Callout icon="⚖️">
`char` buffers are fastest, but they trade safety for performance. In most code paths, `std::string` with `reserve` is a better balance.
</Callout>

### String building summary
<PerformanceBars items={[{label:"std::format",time:21.35,color:"#ff353a"},{label:"std::string concat",time:12.38,color:"#aaa51a"},{label:"char buffer",time:7.78,color:"#1ecb21"}]} />

---

## Number to string conversion

There is one more small detail that is easy to miss when building strings on a hot path: converting numbers to text.

A common approach is to use `std::to_string`:

```cpp
const int value = static_cast<int>(args[0].asNumber());

std::string res;
res.reserve(64);

res.append(std::to_string(value));
res.append(":");
res.append(std::to_string(value));
```

This code is simple and readable, but `std::to_string` returns a new `std::string` for every conversion. Depending on the standard library implementation and the number size, this can allocate and create temporary objects that are then copied or moved into the final string. In this example, we create two temporary strings and then append them into the final result.

**Benchmark (100,000 calls)**

```cpp
std::to_string: 16.27ms
```

For most code, this is perfectly fine. But if this runs very frequently, those temporary allocations can become visible.

A lower-level alternative is `std::to_chars` (C++17):

```cpp
const int value = static_cast<int>(args[0].asNumber());

char buffer[64];
char* ptr = buffer;
char* const end = buffer + sizeof(buffer);

auto [p, ec] = std::to_chars(ptr, end, value);
ptr = p;

*ptr++ = ':';

auto [p2, ec2] = std::to_chars(ptr, end, value);
ptr = p2;

*ptr = '\0';
```

`std::to_chars` writes directly into the provided buffer. It does not allocate, does not create temporary strings, and does not depend on locale formatting. This makes it a good fit for hot paths where the output format is simple and the maximum size is known.
Typical use cases include IDs, counters, timestamps, offsets, sizes, and compact protocol strings.

<Callout icon="⚠️">
When using `std::to_chars`, always check the returned error code in production code. If the buffer is too small, `ec` will be set to `std::errc::value_too_large`, and the output should not be used.
</Callout>

**Benchmark (100,000 calls)**

```cpp
std::to_chars: 9.75ms // 1.7x Faster
```

That is **1.7x** faster with no changes to the output format.

The trade-off is the same as with manual `char` buffers: the code is faster, but also more explicit and easier to get wrong. For regular application code, `std::to_string` is usually the better default. For tight native loops, `std::to_chars` can avoid unnecessary allocations.

### Number conversion summary

<PerformanceBars items={[{label:"std::to_string",time:16.27,color:"#ff353a"},{label:"std::to_chars",time:9.75,color:"#1ecb21"}]} />

---

## Final thoughts

The topics in this post — data shape, API shape, string building, and number conversion — can have a large practical impact after the broader architectural decisions from the [first part](/make-jsi-run-faster).

The main takeaways:

-   if you need to pass numeric arrays from C++ to JS, use `ArrayBuffer` or `MutableBuffer` instead of an array of objects

-   if a function accepts a type parameter, pass a numeric index instead of a string and consider using a lookup table

-   if you build URLs or similar strings on a hot path, a stack `char` buffer can be much faster than `std::format`, as long as input size is controlled

-   if you convert numbers to strings in a hot path, consider `std::to_chars` to avoid temporary string creation

These optimizations do not require changing the whole module architecture. They mostly come from choosing the right data representation.

The biggest performance wins in JSI often do not come from clever algorithms, but from choosing the right data representation and minimizing boundary crossings. In many cases, the difference between a naive and a well-shaped API is not 10–20%, but an order of magnitude.



Part 2: Making JSI Faster with more Efficient Data Structures

Data shape: from objects to raw memory

Array of Objects

Flat Array

ArrayBuffer

The MutableBuffer contract

Reading it on the JS side

Benchmark (100,000 calls)

Data shape summary

API shape: strings vs numbers

API shape summary

String building: convenience vs performance

std::format

std::string concatenation

Char buffer

String building summary

Number to string conversion

Number conversion summary

Final thoughts

Writing JSI code is already fast, but small architectural choices can make it 2–10x slower or faster.

If you’re building a module with pure JSI, it helps to know which patterns make your code as efficient as possible.

This matters most when the module runs in a hot path.

Before diving in, keep one thing in mind: JSI is **fast**, but it is **not free**. Even if your native implementation is very fast, the total cost may still be dominated by:

-   JS ↔ C++ boundary crossing

-   property access resolution

-   virtual dispatch

-   string conversion and comparison

-   heap allocation


So in practice, the biggest wins usually come from choosing the right architecture first, and only then from micro-optimizations.

---

## HostFunction vs HostObject: Avoiding Hidden Property Access Costs

When writing a module, there are several ways to achieve the same result.

For example, imagine we want to create a JSI function that executes some logic. One possible way is to create a `HostObject`, and then use it from JS roughly like this: `MyModule.process(...)`

```cpp
class MyModuleHostObject: public HostObject {
public:
  Value get(Runtime &rt, const PropNameID &prop_name) override {
    const std::string name = prop_name.utf8(rt);

    if (name == "process") {
      return Function::createFromHostFunction(..., [](...) -> Value {
        // Do something
      });
    }
    ...
  }
};
```

But this approach is not the most performant because of several sources of overhead:

-   virtual dispatch through `HostObject::get`

-   conversion from `PropNameID` to `std::string`

-   string comparison for the property name

-   and, in many implementations, creation of a new `HostFunction` during property access


One detail that is easy to miss:

> `HostObject::get()` is executed on **every property access**, not only once during initialization.

In reality, each call looks more like this:

```
JS -> property access -> HostObject::get()
                      -> virtual call
                      -> PropNameID -> utf8 string
                      -> string comparison
                      -> create HostFunction
```

We can expose the same API with far less overhead:

```cpp
Function process = Function::createFromHostFunction(..., [](...) -> Value {
  // Do something
});

rt.global().setProperty(rt, "process", std::move(process));
```

From JavaScript, both approaches look nearly identical: they do the same useful work, and they return the same result:

```cpp
global.MyModule.process(...)
global.process(...)
```

Internally, however, they behave very differently, and the direct `HostFunction` version avoids the property-resolution overhead on every call.

If we benchmark these two approaches by measuring a simple call in a loop, where the function does nothing and just returns some number, we can see the difference.

**Benchmark ( 1,000,000 iterations )**

```cpp
HostObject: 181.09ms
HostFunction: 26.87ms
```

The result is clear: a simple HostFunction call is about **5x** **faster** than the same function exposed through `HostObject`, and in some cases this can bring very noticeable gains.

<Callout icon="💡">
Another important nuance is that if you do stay with `HostObject`, property dispatch itself can still be optimized.

For stable property sets, `jsi::PropNameID`s can be cached and re-used instead of repeatedly converting property names to UTF-8 strings and comparing raw strings on every access.

This does not remove all `HostObject` overhead, but it can reduce part of the lookup cost.

**NitroModules** also helps here out of the box: it caches `jsi::PropNameID`s for repeated comparisons, which is especially useful when many native objects share the same shape.
</Callout>

### Faster Property Dispatch with Hashed Lookup

If the property set is fixed, another possible optimization is to replace long chains of string comparisons with generated or hashed dispatch.
That can reduce branching and repeated string work during lookup.

<Callout icon="💡">
**Nitro Modules** also applies this kind of optimization out of the box through generated dispatch logic, so users can benefit from it without writing the lookup code manually.
</Callout>

Example from **Nitro Modules**

```cpp
switch (hashString(unionValue.c_str(), unionValue.size())) {
  case hashString("electric"): return margelo::nitro::test::Powertrain::ELECTRIC;
  case hashString("gas"): return margelo::nitro::test::Powertrain::GAS;
  case hashString("hybrid"): return margelo::nitro::test::Powertrain::HYBRID;
  default: [[unlikely]]
    throw std::invalid_argument("Cannot convert \"" + unionValue + "\" to enum Powertrain - invalid value!");
}
```

---

## NativeState vs HostObject: Faster Stateful Native Objects

What if we need native state between calls?

In that case, we can use `jsi::HostObject`, but there is another strong option `jsi::NativeState`.

Let's consider a simple example: we have an object that mutates its native state between calls (a counter) and returns the new value back to JS.

If we use `HostObject`, the code might look like this:

```cpp
class HObject: public HostObject {
public:
  int counter = 10;

  Value get(Runtime &rt, const PropNameID &prop_name) override {
    const std::string name = prop_name.utf8(rt);

    if (name == "increment") {
      return Function::createFromHostFunction(..., [](...) -> Value {
        counter++;
        return counter;
      });
    }
    ...
  }
};

...

auto hostObj = Object::createFromHostObject(rt, std::make_shared<HObject>());

rt.global().setProperty(rt, "MyHostObject", std::move(hostObj));
```

We can achieve the same result by using `jsi::NativeState`, and this approach performs significantly better

```cpp
class MyNativeState: public NativeState {
public:
  int counter = 10;
};

...

Object jsObject(rt);

jsObject.setNativeState(rt, std::make_shared<MyNativeState>());

jsObject.setProperty(rt, "increment", Function::createFromHostFunction(
  rt, PropNameID::forAscii(rt, "increment"), 0,
  [](Runtime &rt, const Value &thisVal, const Value *args, size_t count) {
    auto nativeState = thisVal.asObject(rt).getNativeState<CustomNativeState>(rt);
    nativeState->counter++;
    return nativeState->counter;
  }));

rt.global().setProperty(rt, "MyObjectNativeState", std::move(jsObject));
```

In this example, we create a plain JS object, attach `NativeState` to it, add one property to that JS object which is just a simple `HostFunction`, and inside that function we access the `NativeState` from `thisVal`.

Then, just like before, we put that object into the runtime under the name we want.

On the JS side, we use it like this:

```cpp
MyHostObject.increment()
MyObjectNativeState.increment()
```

From JavaScript, the API looks the same. Let’s now look at the benchmark.

**Benchmark (1,000,000 iterations)**

```cpp
HostObject: 188.20ms
NativeState: 38.19ms
```

The benchmark shows NativeState is again roughly **5x** **faster**.

<Callout icon="💡">
**Nitro note** :

If you are using **Nitro Modules**, this optimization is already built into the default object model.

Nitro HybridObjects are backed by `jsi::NativeState` rather than `jsi::HostObject`, so this class of performance improvement comes largely out of the box.
</Callout>

### Why NativeState Performs Better

There is no magic here. The main reason is simple: NativeState removes an entire layer of dynamic property-resolution overhead:

-   no virtual dispatch through `HostObject::get`

-   no property-name lookup via `PropNameID -> std::string`

-   no string comparison

-   direct access to the native pointer through `thisVal.asObject(rt).getNativeState(...)`


So if you need a JSI object with internal native state and you want maximum performance, it is worth considering `Object + NativeState` instead of `HostObject`.

### When NativeState Is the Better Choice

This pattern is especially attractive when:

-   the set of methods is known upfront

-   method names are stable

-   state lives naturally on the native side

-   you want object-like JS API, but without paying `HostObject` costs on every access


In other words, if you do not need dynamic property interception semantics, `NativeState` is often a much better fit.

---

## Stack Allocation vs Heap Allocation

If the size of the string is known, or at least if the maximum size is known ( for example, `< 512` ), and you need to create that string during execution, prefer working on the stack.

Let’s look at a simple example.

Imagine we need to build a string from input data. It could be anything, but for simplicity we will just fill it with the character **'A'**.

```cpp
std::string buf;
buf.resize(256);

for(int i =0; i < 256; ++i){
  buf[i] = 'A';
}

return String::createFromAscii(rt, buf);
```

Next, let’s speed this code up by replacing `std::string` with a `char` array:

```cpp
char buf[256];

for(int i =0; i < 256; ++i){
  buf[i] = 'A';
}

return String::createFromAscii(rt, buf, 256);
```

The logic is the same, but the performance characteristics are different.

**Benchmark ( 1,000,000 iterations )**

```cpp

std::string: 146.70ms
char buf[256]: 46.64ms
```

The result shows that `char buf[256]` is about **3x faster**.

### Why Stack Allocation Wins

The main reasons are usually:

-   no heap allocation

-   no allocator overhead

-   better locality for short-lived data

-   fewer indirections


A stack buffer is just local memory with a fixed size known at compile time. In contrast, once `std::string` grows beyond its small internal buffer, it typically requires heap allocation.

### Important note about `std::string`

One nuance is worth mentioning:

`std::string` is not always heap-allocated. Most standard library implementations use **SSO** (Small String Optimization), which means short strings can be stored directly inside the `std::string` object itself.

That optimization only helps for small strings, commonly around 15–23 bytes depending on the implementation and platform. In this example we use 256 bytes, so this case is well beyond SSO and will typically require heap allocation.

### Use `createFromAscii(...)` When Data Is ASCII

<Callout icon="💡">
If the string contains only ASCII characters, `jsi::String::createFromAscii(...)` is usually a better fit than `createFromUtf8(...)`.

ASCII is a strict subset of UTF-8, but the ASCII-specific constructor communicates a stronger invariant and may avoid some UTF-8 handling work. So if your native code already knows the data is ASCII-only, it is worth making that explicit.
</Callout>

In this example:

```cpp
return String::createFromAscii(rt, buf, 256);
```

the buffer does **not** need to be null-terminated, because the length is provided explicitly. That is an important detail, because when the length is known, passing it directly avoids the need to scan for `'\\0'`.

So if the size is known and the resulting string is ASCII-only, this pattern is usually preferable.

### Use `createFromUtf16(...)` When Data Is Already UTF-16

If your native code already holds the string in UTF-16 form, `String::createFromUtf16(...)` can also be a better choice.

In that case, you may avoid converting the data to UTF-8 first and then making the JS runtime decode it again.
So in practice, the best constructor is often the one that matches the representation you already have in memory:

-   ASCII-only data -> `createFromAscii(...)`

-   UTF-8 data -> `createFromUtf8(...)`

-   UTF-16 data -> `createFromUtf16(...)`


---

## A Smaller but Useful Optimization

Let us look at one more small optimization example.

Suppose we have a function that performs some work and creates a new string:

```cpp
std::string hexdigest(){
  static const char hex[] = "0123456789abcdef";

  char buf[33];

  for (int i = 0; i < 16; i++) {
    buf[i * 2]     = hex[(i >> 4) & 0xF];
    buf[i * 2 + 1] = hex[i & 0xF];
  }

  buf[32]=0;
  return std::string(buf);
}

...

std::string res =  hexdigest();

return String::createFromAscii(rt, res);
```

We can try a small optimization and then look at the result:

```cpp
void hexdigest_char(char* buf){
  static const char hex[] = "0123456789abcdef";

  for (int i = 0; i < 16; i++) {
    buf[i * 2]     = hex[(i >> 4) & 0xF];
    buf[i * 2 + 1] = hex[i & 0xF];
  }
  buf[32]=0;
}
...

char buf[33];

hexdigest_char(buf);

return String::createFromAscii(rt, buf, 32);
```

**Benchmark ( 1,000,000 iterations )**

```cpp
hexdigest: 60.36ms
hexdigest_char: 45.95ms
```

There is still a measurable improvement here: about 1.3x.

### What Changed Under the Hood

The optimized version avoids:

-   creating a temporary `std::string`

-   copying data from the local buffer into that string

-   extra heap-related work once the returned string leaves the local scope


This is not a huge architectural optimization like `HostFunction vs HostObject`, but in hot code it can still be worth it.

---

## Reduce JS ↔ C++ Boundary Crossings

Even when the native implementation is already optimized, too many crossings between JS and C++ can still dominate the total runtime.

Every call usually includes:

-   entering native runtime

-   reading and validating arguments

-   converting values between JS and C++ representations

-   wrapping the return value back to JS


So in practice, **many tiny calls are often worse than fewer larger calls**, even if each individual call is fast.

That means after applying low-level optimizations, the next thing worth looking at is often API shape:

-   can several calls be merged into one?

-   can work be batched?

-   can intermediate JS-visible objects be avoided?


This is not a JSI-specific trick - it is just one of the main cost drivers in real systems.

---

## Final Thoughts: Optimize the Right Things

JSI is already fast, but maximum performance comes from good architecture and smart memory choices.

The biggest wins usually come from simple decisions:

-   prefer `HostFunction` over `HostObject` when state is not needed

-   prefer `Object + NativeState` over `HostObject` when native state is needed

-   prefer stack buffers when size is known

-   avoid unnecessary temporary allocations

-   reduce JS ↔ C++ crossings in hot paths


If your code runs occasionally, these optimizations may not matter.

But if your code sits on a hot path, small decisions like these can make a very noticeable difference.

<Callout icon="💡">
If you want to avoid dealing with many of these low-level JSI optimizations manually, **Nitro Modules** can give you many of them out of the box.
</Callout>


Part 1: How to Make Pure JSI Code Faster in React Native

HostFunction vs HostObject: Avoiding Hidden Property Access Costs

Faster Property Dispatch with Hashed Lookup

NativeState vs HostObject: Faster Stateful Native Objects

Why NativeState Performs Better

When NativeState Is the Better Choice

Stack Allocation vs Heap Allocation

Why Stack Allocation Wins

Important note about `std::string`

Use `createFromAscii(...)` When Data Is ASCII

Use `createFromUtf16(...)` When Data Is Already UTF-16

A Smaller but Useful Optimization

What Changed Under the Hood

Reduce JS ↔ C++ Boundary Crossings

Final Thoughts: Optimize the Right Things

QR and Barcode Scanning in React Native with VisionCamera V5

Why use VisionCamera for barcode scanning?

Install VisionCamera V5

Request Camera Permissions

Fastest Path: `<CodeScanner />`

Production Setup: `useBarcodeScannerOutput(...)`

Tuning Scan Resolution

Full Control: Frame Processors

Drawing an overlay

Understanding the Barcode Result

Supported Barcode Formats

iOS-Only Alternative: `CameraObjectOutput`

Which Scanner API Should You Choose?

Common Gotchas

How Margelo Helped Discord Improve React Native's New Architecture Performance

How Reanimated Powers Animations

What Actually Drives a Reanimated Animation

How Shared Values Reach Your Components

Crossing Into Native: The C++ Runtime

Understanding Fabric's Shadow Tree

Why All Updates Go Through `commit(...)`

The Real Performance Bottleneck

Why Even Opacity Became Expensive

The Fix That Restored Smoothness

Real-World Results

What's New in VisionCamera V5?

Why V5 matters

Full rewrite to Nitro

Nitro's five-year path

Better performance, everywhere

No more hand-written JSI

The new Constraints API

More resolutions

Outputs as separate objects

In-memory Photo

New Docs

Manual AE/AF/AWB

Full Video Dynamic Ranges API (SDR, HDR, Log)

More focus() control

Focus now works in Skia

Coordinate System Conversions

A new integrated QR/Barcode Scanner

New Native Object Output

Depth Data Streaming

RAW Capture

Imperative API

Multi-Cam Camera Sessions

The new GPU-accelerated Resizer

Modularized packages

react-native-worklets

Native Frame Processor Plugins are now Nitro Modules

Extensible design with custom native CameraOutputs

Try VisionCamera V5