jlongster / absurd-sql

sqlite3 in ur indexeddb (hopefully a better backend soon)
MIT License
4.18k stars 100 forks source link

Storing Blobs and startup time #11

Open micahjon opened 3 years ago

micahjon commented 3 years ago

Hi, first off, nice job on this project!

I work on a photo editing / graphic design webapp where we auto-save the user's project in IndexedDB. Most of what we're saving is binary image Blobs. I'm trying to get a sense for the trade-offs of using your library for our use case, and have two questions:

  1. Do you have a sense for the performance of storing Blobs in IndexedDB vs using this library? I'm assuming there'd be the cost of converting the Blob to an ArrayBuffer so it can be shared with the worker, and converting the ArrayBuffer back to a Blob when reading it.

  2. Startup time really matters for our app, as we need to read the user's auto-saved Blobs from IndexedDB and render them to canvas as quickly as possible. Am I right in thinking startup would be slower with sql.js b/c of the need to boot up the worker and also do the ArrayBuffer -> Blob conversion?

Really appreciate your feedback on this. Thanks!

jlongster commented 3 years ago

Hello!

Do you have a sense for the performance of storing Blobs in IndexedDB vs using this library?

For that use case, using SQLite is probably not appropriate. Storing large files that don't need partial writes (whenever a change needs to be written out, you can just write the whole file) is going to be faster than storing in SQLite that writes it in chunks, because you can do just 1 large write instead of making SQLite write blocks, which probably would be a couple writes.

It would probably break even -- in my experience, a small variance of writes doesn't change performance if it's all in the same transaction. Opening a transaction is the slowest part, and doing 1 v 5 writes within it is the same perf.

SQLite makes more sense if you storing a lot of application data that is made up small pieces that need to be individually queried/filtered/updated.

Am I right in thinking startup would be slower with sql.js b/c of the need to boot up the worker and also do the ArrayBuffer -> Blob conversion?

Yes, it would definitely be slower. SQLite.js needs to be initialized, opening a file would spawn a worker, and then it would be ready. This is more appropriate for apps that can take that cost once on app startup, and then users use it for a long time. (Note that it's still pretty fast, but if startup time is crucial there is overhead here)