Some discovers regarding wa-sqlite

[quolpr]

I was discovering wa-sqlite (thanks to @rhashimoto !), and it seems that unwind/rewind doesn't have such performance impact as James said:

Another option would be to use Asyncify, an Emscripten technique for turning sync C calls into async ones. However, there’s no way I’m going to touch that. It works by transforming the entire code to unwind/rewind stacks, causing a massive perf hit and bloating the binary size. It’s just too invasive and would force SQLite to have an async API.

As I understand, it makes stack unwind/rewind only when it needs to read/write the data from IDB, and data reading/writing will always have the biggest bottleneck. Also, you can whitelist which functions should be asyncified. So actually the performance impact is not as high as it could be.

Also, here is a good video about asyncify: https://www.youtube.com/watch?v=qQOP6jqZqf8

So, maybe we should switch absurd-sql to use asyncify. As the other benefit, we will not need those COOP headers that decrease the ability to use aburd-sql a lot (like you are not able to use iframe, embed youtube videos etc etc)

[quolpr]

Buuut, on the other hand, there is article: https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html

Which says:

So far we talked about code size. The numbers for speed are mostly similar, or better - that is, if the binary is 20% bigger, it tends to be at worst 20% slower. However, I did notice one large outlier, SQLite, on which the slowdown is around 5x. That appears to be because of the huge interpreter-like function, which goes from 150K of binary (already big!) to 300K. The larger problem is probably with the locals: they go from 25 to 27, which doesn’t seem so bad (Binaryen works hard to keep that number low!) but they hide the fact that all the extra branches and the saving/restoring code for the locals increases their live ranges dramatically - for many of them, across the whole function, which means a lot more interference, spilling and so forth; VMs may also limit compilation to the baseline tier on such pathological code. A 5x slowdown is not that surprising on such an extreme case.

I am going to test it more, and I will return with the results

[quolpr]

I was able to get the same performance with wa-sqlite result as absurd-sql has! Here is more info sql-js/sql.js#447 (comment)