> On Feb 12, 2020, at 10:10 AM, Henrik Johansson <dahankz...@gmail.com> wrote: > > Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times better > so that particular example isn't really helping the GC case. > > I don't mind the GC myself but I hear the "GC is actually faster" often and > it seems not to be true in the wild although I am sure theoretical cases can > be envisioned.
GC *can* be faster, but it depends on the workload. I don't believe in universals here. If you have a lot of random allocations, and a GC/allocator that's designed for that, it's great. Go works well for random-access workloads; it tends to have some issues with database workloads, which have more linear allocations and a different object lifecycle. Check out the discussions on caching algorithms for dgraph for some very interesting points of view on that. People resigned themselves to writing custom allocators for purpose-specific things in the game engine world in C/C++ a long time ago. In Go, you could do the same for specific use cases if you wanted as well, though you'd lose the advantages of GC (though I'd argue that in a database, if you can't track the objects you own, you're in for a world of hurt anyway). Interacting with the allocator, as well as OS-level virtual memory structures, has long been a facet of database and similar design in the C/C++ world, and it's only escapable in the higher-level language world (e.g. Go, Java) if you want to avoid any discussion of performance issues. If you haven't had to consider structures like B-trees and B-heaps to optimize for various virtual memory scenarios, you haven't delved deeply enough into the problem space to be talking about whether GC is "better" or not, and once you have, you'll probably realize that there's not a simple answer to that. - Dave -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CEEF5C7A-D698-4F18-BB7F-F038569BEAEA%40gmail.com.
