On Wednesday, March 6, 2019 at 5:44:21 AM UTC-8, Robert Engels wrote: > > As I pointed out long ago on stackoverflow the benchmark games are > seriously flawed and should not be used for language performance > comparisons. > > As a simple example, look at binary trees. In all of the “fast” > implementations, they resort to specialized memory pools that wouldn’t be > useable in a highly concurrent system. The Go and Java versions use off the > shelf memory management so the code complexity comparisons are not even > close. I’m sure you could replicate the performance using off heap > structures in Go/Java but who would want to? >
And yet, you also say — "So for uses like highly mutable binary trees - Go’s lack of a generational garbage collector really hurts <https://groups.google.com/d/msg/golang-nuts/KcieYzCk0fw/c3HcfI1YCgAJ>." Does that difference show between the Go and Java programs which use "off the shelf memory management" ? -- 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. For more options, visit https://groups.google.com/d/optout.
