←back to thread

Sqlite3 WebAssembly

(sqlite.org)
506 points whatever3 | 3 comments | 15 Oct 24 17:45 UTC | HN request time: 0.41s | source
Show context
TiredGuy ◴[15 Oct 24 18:04 UTC] No.41851263[source]▶
So after downloading from the official downloads page and stripping away all the mjs files and "bundler-friendly" files, a minimal sqlite wasm dependency will be about 1.3MB.

For an in-browser app, that seems a bit much but of course wasm runs in other places these days where it might make more sense.

replies(8): >>41851337 #>>41851618 #>>41851622 #>>41851724 #>>41851840 #>>41852258 #>>41854092 #>>41855860 #
1. hawski ◴[15 Oct 24 19:32 UTC] No.41852258[source]▶
Is there a way to statically compile an application with SQLite and the result WASM was smaller. So for example I have an app that would use only a specific subset of SQLite. Could the SQLite's WASM be built with this in mind cutting down on code that is not used? Or is there a way to prune it having the used API surface?

In a regular compiler/linker scenario it would just be a static compilation. Here we have a JS app and WASM library.

replies(2): >>41852312 #>>41854865 #
2. hoten ◴[15 Oct 24 19:39 UTC] No.41852312[source]▶
Since SQL takes arbitrary strings as input, this would require explicit compiler flags to disable the knobs you don't want. Can't rely on excluding unused symbols really.
3. sgbeal ◴[16 Oct 24 01:49 UTC] No.41854865[source]▶
> Could the SQLite's WASM be built with this in mind cutting down on code that is not used?

The pending 3.47 release has some build-side tweaks which enable a user to strip it down to "just the basics," but we've not yet been able to get it smaller than about 25-30% less than it otherwise is:

    cd ext/wasm
    make barebones=1 ; # requires GNU Make and the Emscripten SDK
Doing that requires building it yourself - there are no plans to publish deliverables built that way.

The build process also supports including one's own C code, which could hypothetically be used to embed an application and the wasm part of the library (as distinct from the JS part) into a single wasm file. Its primary intended usage is to add SQLite extensions which are not part of the standard amalgamation build.

> Or is there a way to prune it having the used API surface?

Not with the provided JS pieces. Those have to expose essentially the whole C library, so they will not be pruned from the wasm file.

However, you could provide your own JS bindings which only use a small subset of the API, and Emscripten is supposedly pretty good about stripping out C-side code which neither explicitly exported nor referenced anywhere. You'd be on your own - that's not something we'll integrate into the canonical build process - but we could provide high-level support, via the project's forum, for folks taking that route.