kai zhu

can we simplify the distribution by merging `sql-asm-memory-growth.js` into `sql-asm.js`? i think the only reason for `asm.js` these days is legacy-support where performance doesn't matter.

don't know about rtree, but the following full-text-search example works fine in the online-demo: ```sql -- Create an FTS table DROP TABLE IF EXISTS pages; CREATE VIRTUAL TABLE pages USING...

sql.js runs entirely in memory. i'm not sure its practical to load the 2gb enron dataset w/ sql.js. my experience with chrome-browser (windows version) is that it will frequently crash...

thx for feedback on real-world performance. that's always good-to-know : )

long-term i agree sql.js should be used instead of native in nodejs. however, 1. webassembly is still experimental and hidden behind a flag in nodejs (making it unsuitable for production...

depends on browser. for chrome it appears to be 4gb (https://v8.dev/blog/4gb-wasm-memory). My experience however, is chrome-browser (windows 10) starts to freeze and crash when working with datasets over 1gb.

good question. the following benchmark indicates asm2 is 1-6% slower running queries on a 60mb database: ``` // asm2 = LEGACY_VM_SUPPORT + ALLOW_MEMORY_GROWTH // used build-artifacts from https://github.com/sql-js/sql.js/actions/runs/320372611 for asm2...

also the difference in size is < 1%: ``` asm asm2 sql-asm-debug.js 10,865,349 10,896,696 bytes worker.sql-asm-debug.js 10,867,832 10,899,179 bytes sql-asm.js 2,383,575 2,389,992 bytes worker.sql-asm.js 2,386,058 2,392,475 bytes ```

k. would updated patch with following be ok?  

latest-patch removes redundant npm-tests on `sql-asm-memory-growth.js`, since its now essentially a carbon-copy of `sql-asm.js` (plus a deprecation-warning header). this simplifies sunsetting `sql-asm-memory-growth.js` in some future-release by simply deleting the following...