eskiuReactVision: cutting memory in an AR/VR rendering engine
The setup
ReactVision builds ViroCore, the native AR/VR rendering
engine behind @reactvision/react-viro on iOS, Android, Meta
Quest, and visionOS. It is a large, long-lived C++ codebase, on the order
of 2,200+ files and ~23 MB of engine source, split across
the parts you'd expect of a real-time renderer:
| Subsystem | Scale |
|---|---|
| Renderer | ~800 files |
| Physics | ~480 files |
| Scene graph | ~110 files |
| Image / texture, materials, lighting, text, particles | the rest |
It ships to phones and headsets, where memory is the scarce resource: every texture buffer, scene-graph node, and per-frame allocation counts. The hot, memory-sensitive paths (image and texture preprocessing, the scene graph, physics) are exactly the kind of native code where how you allocate decides the footprint.
Why Eskiu fit
The team didn't want to rewrite the engine, and didn't want to trade C++'s control for a language with a garbage collector or a heavy runtime. Eskiu's shape matched the constraints:
- Native, no runtime. Compiles to native code through LLVM, with no collector and nothing to embed, so the binary footprint stays predictable.
- Memory you account for.
alloc<T>(N)/free(ptr)live in the source. A migrated component's allocation pattern is explicit and auditable, not hidden behind a framework. - C ABI in and out. Eskiu speaks the C ABI directly and links as a plain native object. A module drops into the existing C++ engine, called from it and calling back into it, without rewriting the host.
- Modern where it helps. Sum types with
match, async/await, templates: current-language ergonomics without giving up the systems layer.
The approach
Selective, not a rewrite: take one memory-sensitive C++ component, re-implement it as an explicit Eskiu module, and link it in over the C ABI. The surrounding engine doesn't change; it sees the same symbols. Each migrated module is small enough to audit and measure on its own, so the footprint win is attributable. On the modules moved so far: ≈85% less memory.
So the same language that boots a bare-metal ARM64 kernel also drops a memory-tight module into a C++ rendering engine. One language across the stack, used where it pays off.