perf: materialize result rows on demand

Offen
  • Stimmt etwas nicht?
#398 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
javascript, react-native, sqlite
Bereich
databases, mobile-dev, performance

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
C
Sterne
582
Forks
53
Ø Merge
1 T. 17 Std.
Gemergte PRs (30 T.)
10

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus margelo/react-native-nitro-sqlite

Alle Issues in margelo/react-native-nitro-sqlite

Ähnliche Issues

Weitere Issues zu C

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.