4 ms·
Most Go apps can get better than advanced Java GC level allocation-memory performance simply by applying "sync.Pool" (http://golang.org/pkg/sync/#Pool http://go
by voidlogic 12y ago
Most Go apps can get better than advanced Java GC level allocation-memory performance simply by applying "sync.Pool" (http://golang.org/pkg/sync/#Pool http://golang.org/pkg/sync/#Pool) on applicable pain points.
Its also worth mentioning using a custom allocator + mmap is possible in Go if you really needed it.
Go is also better than Java about using stack allocation for objects.
- batbomb 12y agoI'd like to see some research to backup your first claim if you can point me to some.
- voidlogic 12y agoYou want evidence that a object pool with thread-local caching is faster than a garbage collector? Barring major implementation mistakes this should be self-evident, but you could easily write some benchmarks to verify. Its worth noting that if the Java GC was good enough people would not bother to write object pools in Java- but they do. And Go has a very advanced GC/mutliprocessor aware object pool implementation built in its stdlib. In an typical object pool only allocation up to the peak concurrent demand for the given object type will ever be allocated and the kicker is that allocation will only happen once. Adding thread-local caching means that that will scale well on multiprocessor systems. TL;DR: A system that does not generate garbage is going to be faster than a system that does. My argument is that effective use of a good object pool implementation in Go is faster than even a more advanced garbage collector would be.