I should mention that if you use this, somebody will eventually discover this line of code and be unhappy.
https://gitlab.com/cznic/libc/-/blob/v1.22.2/libc_openbsd_am...
Go port of SQLite without CGo
21–30 of 122 posts
Re: Go port of SQLite without CGo
#22It's a really neat project. I did some simple benchmarks of it and it was between 10% slower to twice as slow. Which depending on your use case isn't that bad! https://datastation.multiprocess.io/blog/2022-05-12-sqlite-i...
I raised this question on twitter awhile back and the response that I got was that (for read-only tasks) the connection string might ameliorate this. I haven't been able to test it, though:
Re: Go port of SQLite without CGo
#23It's a really neat project. I did some simple benchmarks of it and it was between 10% slower to twice as slow. Which depending on your use case isn't that bad! https://datastation.multiprocess.io/blog/2022-05-12-sqlite-i...
at segment we benchmarked https://github.com/segmentio/ctlstore against this driver. We saw about a 50% hit to read performance, so we didn't move forward with it, but the improvements in service build times were really appealing.
Re: Go port of SQLite without CGo
#24It's a really neat project. I did some simple benchmarks of it and it was between 10% slower to twice as slow. Which depending on your use case isn't that bad! https://datastation.multiprocess.io/blog/2022-05-12-sqlite-i...
at segment we benchmarked https://github.com/segmentio/ctlstore against this driver. We saw about a 50% hit to read performance, so we didn't move forward with it, but the improvements in service build times were really appealing.
Really tho, how much is build time vs runtime? Maybe is just work small projects but I rarely care about build time. Am I missing something?
Re: Go port of SQLite without CGo
#25Re: Go port of SQLite without CGo
#26Earlier quoted context omitted.
What makes it slower?
It’s hard for Go to beat C in a straight benchmark - Go is garbage collected and allocations often have extra overhead due to the memory layout of interfaces.
In addition, a lot of optimizations (like loop unrolling) are left on the table to preserve Go's fast compile times.
Re: Go port of SQLite without CGo
#27I've use this. Slightly slower, but for my use case that was fine (a small blog) and immeasurably better doing away with all the CGO hassle. Especially when I might cross compile to an Arm architecture, or some docker container that uses a different approach to the c libraries (like Alpine vs Ubuntu Server or whatever) it was always a hassle, and thats all gone away now. Always seemed silly that one of the most popul…
Pretty much any database is NOT written in Go, so what's the difference?
Etcd, CockroachDB, InfluxDB, Consul. There are more.
Re: Go port of SQLite without CGo
#28What’s the point of something like this instead of just using SQLite? Seriously, “foo but in bar!” is not exactly the sort of thing that solves real problems for most people.
Re: Go port of SQLite without CGo
#29Earlier quoted context omitted.
at segment we benchmarked https://github.com/segmentio/ctlstore against this driver. We saw about a 50% hit to read performance, so we didn't move forward with it, but the improvements in service build times were really appealing.
Really tho, how much is build time vs runtime? Maybe is just work small projects but I rarely care about build time. Am I missing something?
If you have a lot of people and a lot of different builds it can become increasingly significant. It wasn't in our case, but it felt like it could have become so. And a lot of services wouldn't really notice too much if the occasional read from disk was slower, given that the nature of the data was control data.
Re: Go port of SQLite without CGo
#30If you cross-compile (which everybody using macOS to developer for Linux servers does), it's annoying to introduce SQLite to your project, because immediately the conventional `GOOS= GOARCH= go build` trick stops working. But, in case it's helpful, it's also really easy to set up a full cross-compiling environment, either with Zig or with Filippo's musl-cross: https://words.filippo.io/easy-windows-and-linux-cross-com…
Is there something like this for cross-compiling to FreeBSD?
You can check how ClickHouse is cross-compiled for FreeBSD.
1. https://github.com/ClickHouse/sysroot/
2. https://github.com/ClickHouse/ClickHouse/blob/master/cmake/f... and the `CMAKE_TOOLCHAIN_FILE` variable.