---
title: "Part 2: Making JSI Faster with more Efficient Data Structures"
url: https://daily.dev/posts/part-2-making-jsi-faster-with-more-efficient-data-structures-avm06bqkf
source_url: https://margelo.com/blog/make-jsi-run-faster-2
type: article
source: "Nitro Modules"
published: 2026-08-23T12:23:31.949Z
updated: 2026-08-23T12:57:32.717Z
tags: ["performance", "react-native", "c++", "data-structures"]
reading_time: 12
upvotes: 0
comments: 0
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Part 2: Making JSI Faster with more Efficient Data Structures

**[Nitro Modules](https://daily.dev/sources/margelo)** · 12 min read · 0 upvotes · 0 comments

## Summary

Deep dive into optimizing React Native JSI native module performance through data representation choices. Benchmarks show returning arrays of objects is up to 30x slower than using ArrayBuffer/MutableBuffer for numeric data crossing the C++/JS boundary. Passing type parameters as numeric indices with lookup tables beats string comparisons, and stack-allocated char buffers or std::to_chars outperform std::format and std::to_string for hot-path string building. Concrete millisecond benchmarks for 100,000 calls accompany each technique.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://margelo.com/blog/make-jsi-run-faster-2>

## Questions this post answers

### Why is returning an array of objects from a JSI native function so slow compared to ArrayBuffer?

Each object requires a separate JS heap allocation and every setProperty call crosses the JSI boundary, adding GC pressure and per-call overhead. In a benchmark of 100,000 calls returning 50 points, an array of objects took 1036.50ms versus 34.81ms using ArrayBuffer with a MutableBuffer subclass, a roughly 30x difference, because ArrayBuffer shares native memory directly with JS with zero per-element calls.

_Developers tuning native module boundaries can track C++ and JSI performance patterns like this on daily.dev._

### Is std::to_chars faster than std::to_string for converting numbers to strings in a hot loop?

Yes, std::to_chars is about 1.7x faster than std::to_string in a benchmark of 100,000 calls (9.75ms vs 16.27ms), because it writes directly into a provided buffer without allocating temporary std::string objects or depending on locale formatting. It suits hot paths with simple, bounded output like IDs, counters, or timestamps, while std::to_string remains the better default for regular code.

_Anyone optimizing C++ hot paths can follow comparisons like this on daily.dev when choosing string conversion approaches._

### Should I pass a string or a number when a JSI function needs to select a type from JavaScript?

Pass a numeric index rather than a string. Comparing a JS string requires asString(rt).utf8(rt), which allocates and copies across the JSI boundary, then runs multiple string comparisons, taking 12.88ms per 100,000 calls versus 9.13ms for a switch on an int and 8.67ms for a lookup table indexed by that int, the fastest and cleanest option.

_Developers designing native module APIs can compare JSI parameter patterns like this on daily.dev._

## Similar posts on daily.dev

- [React Native Internals: Decoding JS-to-Native Communication in the New Architecture](https://daily.dev/posts/react-native-internals-decoding-js-to-native-communication-in-the-new-architecture-mazf9aedd) · Medium · 0 upvotes · 0 comments

---

Tags: [#performance](https://daily.dev/tags/performance), [#react-native](https://daily.dev/tags/react-native), [#c++](https://daily.dev/tags/c++), [#data-structures](https://daily.dev/tags/data-structures)

[View this post on daily.dev](https://daily.dev/posts/part-2-making-jsi-faster-with-more-efficient-data-structures-avm06bqkf)