Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

perf: materialize result rows on demand

Abierto
  • ¿Algo no está bien?
#398 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, react-native, sqlite
Área
databases, mobile-dev, performance

Línea de trabajo

Start with the managed query wrapper and PR #389's shared positional storage. Define and measure first-row, partial, and full consumption behavior, including repeated-index identity, unchanged eager getters and _array behavior, and native/JavaScript memory release. Done means the benchmarks and external-memory tracking cover the requested cases without changing the existing eager contract.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

area:api area:runtime enhancement

The managed query wrapper reads result.results as soon as a query finishes. This converts every returned row into a JavaScript object even when a caller only asks for rows.item(0) or renders a small visible subset. PR #389 reduces native allocation and copying, but its converter still creates the complete JavaScript array on that first getter read.

Add an opt-in native-backed result whose row access converts and caches individual JavaScript rows on demand. Repeated access to an index should return the same row object, and requesting all rows should produce the same values and order as the existing eager API. Keep the current eager result contract unchanged, including _array and repeated getter behavior.

This work can build on #389's shared positional storage. It would reduce JavaScript conversion for partial consumers, but SQLite would still step and store the entire native result. Track the native allocation with Nitro's external-memory reporting and release it when the result is no longer referenced. Compare first-row latency, partial consumption, full consumption, and peak native/JavaScript memory on Release devices.

Related: #30, #62, #389. A bounded cursor is separate work because lazy conversion alone cannot cap native result memory.

Lenguaje dominante
C
Estrellas
567
Forks
53
Merge medio
2 d 5 h
PR fusionados (30 d)
67

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de margelo/react-native-nitro-sqlite

Todos los issues de margelo/react-native-nitro-sqlite

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.