perf: materialize result rows on demand
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- javascript, react-native, sqlite
- Domain
- databases, mobile-dev, performance
Research direction
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.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- C
- Stars
- 567
- Forks
- 53
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 67
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from margelo/react-native-nitro-sqlite
-
area:api area:runtime enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
margelo/react-native-nitro-sqlite#402 ·
Maintainers usually reply within 1 day
-
area:api area:runtime enhancement
Difficulty 5/5 Over a week Newbie friendliness 28/100
margelo/react-native-nitro-sqlite#401 ·
Maintainers usually reply within 1 day
-
area:api area:runtime enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
margelo/react-native-nitro-sqlite#400 ·
Maintainers usually reply within 1 day
-
area:api area:runtime enhancement
Difficulty 5/5 Over a week Newbie friendliness 28/100
margelo/react-native-nitro-sqlite#399 ·
Maintainers usually reply within 1 day
-
area:api area:runtime enhancement
Difficulty 5/5 Over a week Newbie friendliness 48/100
margelo/react-native-nitro-sqlite#397 ·
Maintainers usually reply within 1 day
All issues in margelo/react-native-nitro-sqlite
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Ryan-Millard/Img2Num#681 · 2 comments ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
tursodatabase/libsql#2285 ·