4 ms·
So we aren't using mmap (but we are using WAL), so for one thing there's a lot of buffer and cache copy work going on - I'd expect it's the old classics from st
by raggi 2y ago
So we aren't using mmap (but we are using WAL), so for one thing there's a lot of buffer and cache copy work going on - I'd expect it's the old classics from string.h. WASM is a high level VM though so I'd expect (provided you pass the relevant flags) it should be using e.g. the VMs memory.copy instruction which will bottom out in e.g. v8s memcpy.
we also don't use a common driver, ours is here https://github.com/tailscale/sqlite https://github.com/tailscale/sqlite
sqlite in general should be mostly optimized for the targets it's often built with, so for example it'll expect everything in string.h to be insanely well optimized, but it should also expect malloc to be atrocious and so it'll manage it's own pools.
- ncruces 2y agoOh tailscale! Hi! And thanks for this! Yeah, my Wasm uses bulk memory instructions which wazero bottoms out to Go's runtime.memmove: memory.init, memory.copy, etc are all just runtime.memmove; memory.fill fills a small segment, then runtime.memmove it to exponentially larger segments; etc. memcmp is probably slow though, the musl implementation is really naive. I shall try a simple optimization.
- ncruces 2y agoI got some nice 10x improvements, but they didn't really show up in benchmarks of SQLite. I'm guessing it's mostly memset and memcpy that matter. https://github.com/ncruces/go-sqlite3/issues/257#issuecomment-2780645879 https://github.com/ncruces/go-sqlite3/issues/257#issuecommen...