perf: materialize result rows on demand

Ouverte
  • Quelque chose ne va pas ?
#398 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
javascript, react-native, sqlite
Domaine
databases, mobile-dev, performance

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
C
Étoiles
583
Forks
53
Merge moyen
2 j 2 h
PR mergées (30 j)
36

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de margelo/react-native-nitro-sqlite

Toutes les issues de margelo/react-native-nitro-sqlite

Issues similaires

Plus d'issues C

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.