eskiuReactVision: recortando memoria en un motor de renderizado AR/VR
El contexto
ReactVision desarrolla ViroCore, el motor nativo de renderizado
AR/VR detrás de @reactvision/react-viro en iOS, Android, Meta
Quest y visionOS. Es una base de código C++ grande y de larga vida, del orden
de 2,200+ archivos y ~23 MB de código del motor, repartida entre
las partes que esperarías de un renderizador en tiempo real:
| Subsistema | Escala |
|---|---|
| Renderizador | ~800 archivos |
| Física | ~480 archivos |
| Grafo de escena | ~110 archivos |
| Imagen / textura, materiales, iluminación, texto, partículas | el resto |
Se distribuye a teléfonos y visores, donde la memoria es el recurso escaso: cada buffer de textura, nodo del grafo de escena y asignación por frame cuenta. Las rutas críticas y sensibles a la memoria (preprocesamiento de imagen y textura, el grafo de escena, la física) son justo el tipo de código nativo donde la forma de asignar memoria decide el footprint.
Por qué encajó Eskiu
El equipo no quería reescribir el motor, ni cambiar el control de C++ por un lenguaje con recolector de basura o un runtime pesado. El perfil de Eskiu encajaba con esas restricciones:
- Nativo, sin runtime. Compila a código nativo vía LLVM, sin recolector y sin nada que embeber, así que el footprint del binario se mantiene predecible.
- Memoria que administras.
alloc<T>(N)/free(ptr)viven en el código. El patrón de asignación de un componente migrado es explícito y auditable, no oculto tras un framework. - ABI de C en ambos sentidos. Eskiu habla el ABI de C directamente y enlaza como un objeto nativo plano. Un módulo entra en el motor C++ existente, llamado desde él y llamándolo de vuelta, sin reescribir el host.
- Moderno donde ayuda. Tipos suma con
match, async/await, templates: ergonomía de lenguaje actual sin renunciar a la capa de sistemas.
El enfoque
Selectivo, no una reescritura: tomas un componente C++ sensible a la memoria, lo reimplementas como un módulo Eskiu explícito y lo enlazas por el ABI de C. El motor de alrededor no cambia; ve los mismos símbolos. Cada módulo migrado es lo bastante chico para auditarse y medirse por sí solo, así que la ganancia de footprint es atribuible. En los módulos movidos hasta ahora: ≈85% menos memoria.
El mismo lenguaje en la nube
El otro extremo del stack validó el mismo toolchain. El
decodificador de QR de credencial del INE de Eduardo, un
proyecto personal, un pipeline real de imagen más cripto (extracción de QR,
luego múltiples rondas de AES-256-CBC + RSA-8192), fue reimplementado en Eskiu y
se sirve como una API HTTP. En el pipeline criptográfico corre
2.5× más rápido que la implementación de referencia en C, sobre un
stack construido enteramente con la biblioteca estándar de Eskiu (<http>,
<json>, <base64>, hilos), sin
framework externo.
Así que el mismo lenguaje que arranca un kernel ARM64 bare-metal, y que mete un módulo ajustado en memoria dentro de un motor de renderizado C++, también corre un servicio en la nube. Un solo lenguaje a lo largo del stack, usado donde de verdad rinde.