I already responded. The Go version requires minimal memory for optimum performance. I’m sure a lot of that is due to the buffer chaining/reuse in the implementation.
Still it is an important aspect regardless for systems level tools. Additionally, the Go version requires no warm-up. For this type of application that is not really a concern since it would be very long lived, but it definitely matters for short lived system tools. > On Oct 30, 2018, at 11:33 AM, Glen Newton <glen.new...@gmail.com> wrote: > > I would also be interested in the memory comparison. > > Glen > >> On Tuesday, October 30, 2018 at 1:03:13 PM UTC, T L wrote: >> OP really should compare the memory consumptions of the Java version and Go >> version. >> >> On Monday, October 29, 2018 at 4:53:52 PM UTC-4, robert engels wrote: >>> >>> Hello Gophers, >>> >>> I’ve been chastised in the past regarding some of my Go performance tests - >>> using Java as a baseline. In most of these micro-benchmarks Go has >>> performed more poorly than expected. >>> >>> So, I ported nats (https://nats.io) message broker (which is written in Go) >>> to Java. It is available at github.com/robaho/jnatsd >>> >>> This was an ideal test case, as only the server broker was ported, and all >>> of the client tools and benchmarks could be run unmodified. >>> >>> So, using the Java based broker (under OpenJDK11 with Shenandoah) and the >>> nats bench with defaults: >>> >>> without SSL, 3200k msgs per second >>> with SSL, 900k msgs per second >>> >>> using the Go based server (under Go 1.11) and the same test parameters: >>> >>> without SSL, 5400k msgs per second >>> with SSL, 2600k msgs per second >>> >>> The latency numbers are much closer, but notice the much higher max in Java >>> (attributed to larger GC pauses). It is expected that in the above >>> throughput tests, more GC cycles, thus a much larger penalty. >>> >>> Java: >>> latency avg 191214 min 167079 max 936848 ns >>> Go: >>> latency avg 188338 min 158997 max 588876 ns >>> >>> So, Go shows VERY, VERY impressive performance numbers in a real-world >>> application, and aligns with my thoughts that Go is ideally suited to >>> replacing systems level software currently written in C/C++. >>> >>> Some notes, the Java implementation uses some custom string processing >>> classes to improve performance, but does not use async IO (mainly since >>> doing so with SSL is a huge PITA). The Go server is also FAR more robust in >>> terms of ‘handling slow consumers, handling lots of clients, etc.” >>> >>> I might try modifying the Java to use NIO direct buffers and channels to >>> observe any improved performance. >>> >>> >>> >>> >>> >>> > > -- > 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. -- 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.
