5 ms·
It'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!
by eatonphil 4y ago
It'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-in-go-with-and-without-cgo.html https://datastation.multiprocess.io/blog/2022-05-12-sqlite-i...
- philosopher1234 4y agoWhat makes it slower?
- platzhirsch 4y agoMy guess is that over the years many optimizations have gone into SQLite that would take a lot of effort to catch up to.
- cdogl 4y agoIt’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.
- icholy 4y agoIn addition, a lot of optimizations (like loop unrolling) are left on the table to preserve Go's fast compile times.
- pjmlp 4y agoGccgo is the answer here.
- Patrickmi 4y agoGccgo at its core may be fast but when it comes to how the go frontend interpret it to gcc ir that pales in comparison than just straight up optimizating the Go compiler There’ll more opportunities for more optimizations since they move to SSA ir since 1.5 and in turn compile time will definitely go down
- 59nadir 4y agoI was surprised with the announcement that Go's standard compiler had register allocation for function arguments[0] added to it. This seemed like table stakes for a very long time but it really illustrated just how Go's compiler is much, much simpler than most in many areas. On one hand it makes you wonder how much could be squeezed out of Go and how many basic things they're still leaving out of the compiler. On the other it tells part of the story of why Go compiles fast with the backdrop that despite this lack of work by the compiler people use Go productively all day and deliver services they are happy with from a performance perspective. [0] - https://go.dev/doc/go1.17#compiler https://go.dev/doc/go1.17#compiler (2021-08)
- zimpenfish 4y agoI wonder if they'll ever switch to a "normal = fast compile, low optimisation; release = slow compile, high optimisation" model like Rust. Although I suppose other languages already have the "high optimisation" parts covered (rust, julia, python+numpy, etc.) which might make it a fool's errand.
- Mawr 4y agoIt goes to show the impact of optimizing from top-down instead of bottom-up can have. Go was designed with performance in mind ("mechanical sympathy") as opposed to most other GC languages for which performance was an afterthought. If you get high-level language constructs right, you'll get great performance by default, even with a simple compiler: - structs instead of objects - value types - exposed pointers - straightforward allocation semantics Most compilers out there are busy fighting bad language designs. There's only so much a compiler can do when faced with fat objects hidden behind a spider web of pointers. So they have to do these microoptimizations to claw back at least some performance.
- pjmlp 4y agoIt is a matter of skill, Go can do manual memory management and stack allocation just as well.
- kaba0 4y agoAlso, Go barely optimizes code, that’s how it compiles as fast.
- pkolaczk 4y agoNot only Go compiler is not as good at optimisation as C/C++/Rust/Zig/D compilers, but also Go FFI to C has significant overhead, which means there is often not much point in using low-level Linux APIs for performance advantage. Same problem like with Java. And in a database system you quite likely want a fine degree of control with non-standard stuff.
- deleted 4y ago[deleted]
- yencabulator 4y agoHowever, it is absolutely plausible for Go-calling-Go to beat Go-calling-C-via-CGo, since CGo has plenty of overhead.
- cube2222 4y agoOther than what the other responders said, since it uses a C to Go compiler, I'd imagine the Go code that's generated isn't as fast as handwritten Go code could be.
- Patrickmi 4y ago[dead]
- carbocation 4y agoI 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: https://twitter.com/frioux/status/1483235674228596739 https://twitter.com/frioux/status/1483235674228596739
- collinvandyck76 4y agoat segment we benchmarked https://github.com/segmentio/ctlstore 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.
- djbusby 4y agoReally 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?
- collinvandyck76 4y agoIf 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.
- badtuple 4y agoHonestly, on a non-toy project, build times with cgo are _brutal_. I agree with you usually, but when a build time on a beefy computer switches from under a second to >1min you notice it. Linters and IDEs get slow when they check for errors, tests run slow, feedback drags, and all your workflows that took advantage of Go's fast compile times are now long enough that your flow and mental context disappear. I'm way more lenient with other languages since the tooling and ecosystem are built around long build times. Your workflows compensate. But Go's tooling and ecosystem assume it compiles fast and treat things more like a scripting language. When that expectation is violated it hurts and everything feels like it's broken.
- bombolo 4y agoWhy would you have to recompile sqlite every time? I guess you just need to compile the .a once and then just reuse it? If you're rebuilding it every single time, your build is set up wrong.
- emodendroket 4y agoI’d go so far as to say it’s completely acceptable for 90+% of use cases.