Also, note that the workload that databases need to incur are lot heavier than typical Go applications. > I see this as a no different than taking some pieces of your code and converting them to assembly (utilize SIMD instructions, for e.g.), which Go does as well. ![]() ![]() We’re still using it pretty expansively in all non-critical paths and wherever it’s hard to trace the memory ownership and release. > Go’s code readability, concurrency model, fast compilation, gofmt, go profiler, go vet, performance and so on. I peeked at the reddit conversation earthboundkid mentioned. * Maybe the whole rest of their company's codebase is in Go and they want to use that expertise. * There may be significant other parts of the program where Go/GC is more appropriate. In my experience, porting to Rust really is fairly labor-intensive. * Rust may not have existed or been a reasonable choice when they started coding. In fairness to them, there are plenty of practical reasons they might have ended up here: Note that (as in my other comment) I still think Rust is a better language for this program. It'd still be garbage-collected which they've been trying to avoid, but the allocator would no longer looking through each individual allocation, so maybe it'd zippier about freeing stuff. Or maybe just each Allocator (arena) using the Go allocator for its backing allocations would be okay. These simple allocators would have an "unfair" advantage of not having to go through Cgo. Maybe the arenas reduce the allocations enough (and makes them of reasonably uniform size) such that a simple buddy or slab allocator underneath would beat jemalloc. Batching the frees makes a huge difference, both because there are fewer calls to free and because you have to do less pointer-chasing (with potential cache misses) to decide what calls to make to free. You can totally beat directly using the global allocator by layering arenas on top, whether the global allocator is jemalloc or anything else. In many servers, an arena per request is appropriate. ![]() I think it's fair to say that when not using GC, it's worth looking for a suitable scope for arenas: short-lived, bounded but significant number of allocations. Their Allocator library is really an arena, a special-purpose allocator that was discussed on HN recently.
0 Comments
Leave a Reply. |