4 ms·
Another thing I can think of - Go's interface mechanism overhead is usually significant, and I've also found that the networking stack is slow compared to raw C
by dvirsky 9y ago
Another thing I can think of - Go's interface mechanism overhead is usually significant, and I've also found that the networking stack is slow compared to raw C. When I brought this up on the user group a few years ago I was told that this is a fair price to pay for Go's safety and concurrency abstractions.
I pretty much agree actually. I won't be necessarily writing a database in Go, but for robust and fast application services it's very very good.
- kasey_junk 9y agoThe channel primitives are also slow and it is really painful to write fast alternatives as you have to resort to code gen.
- dvirsky 9y agoyes, and they are heavily used under the hood in the standard library, for things like http connection pooling.
- gtirloni 9y agoRe: databases in Go, I remember seeing a lot of these concerns a few years ago but it looks like many people found a way to make it work: https://github.com/avelino/awesome-go/blob/master/README.md#database https://github.com/avelino/awesome-go/blob/master/README.md#...
- dvirsky 9y agoI actually experimented with a "database" of sorts, a redis compatible server with replication, persistence and an extendable API. It was okay as a toy project but never came close to redis performance, even when it only did ping/pong. Plus it had the issue of stop-the-world GC that was how Go worked back then. Not sure how well it would work today.
- masklinn 9y ago> Another thing I can think of - Go's interface mechanism overhead is usually significant Yes that's a more likely culprit, interfaces mean dynamic dispatch, outside of hand-rolled codegen I don't think Go can statically dispatch abstractions.