Comment by Twirrim
2 days ago
It's wild to me that stdin/stdout is apparently significantly faster than using the API in so many cases.
That's the kind of result that makes me wonder if there is something odd with the benchmarking.
2 days ago
It's wild to me that stdin/stdout is apparently significantly faster than using the API in so many cases.
That's the kind of result that makes me wonder if there is something odd with the benchmarking.
That's an interesting thought. I wonder.
I wonder if the following things make the C driven version slower...
- prepare the send buffers (sqlite side)
- prepare the receive buffers (go side)
- do the call
- get the received data into go buffers of some kind
- free up the send buffers (happens automatically)
- free up the receive buffers (semi automatically in Go).
When using stdin/stdout, the system looks after send/receive buffers. It's simply reading/writing them. No allocation is needed. The stream can be as big or as little as wanted/needed. The OS will look after the integrity of the streams and these are probably fairly well tested subsystems on most operating systems.
stdin/stdout becomes a "library" for "fast data transfer".
Pretty neat.
fwiw, the tailscale fork of Crawshaw’s library has a good number of allocation removals and other optimizations, but cgo is still expensive.
And presumably that implies there's OS context switching going on underneath.
Still, I can see a few downsides. Though sqinn-go is pure Go, the forked process is pure C, so you'll need to either download a prebuilt one (Linux and Windows only atm), or build it yourself. This rather defeats the benefits of Go's killer feature of "single-binary distribution".
Still, I agree it's wild it is so fast.