3 ms·
I'd make a guess in absence of code. Since none of the implementations were IO bound (unsaturated link), I'd bet on memory management as the deciding factor (i
by mritun 14y ago
I'd make a guess in absence of code.
Since none of the implementations were IO bound (unsaturated link), I'd bet on memory management as the deciding factor (it's hard to assume that an authentication service will be CPU bound).
Then it's not difficult to see why Java won. When it comes to garbage collectors, JVM has the best (production) implementation of GC bar none.
Go runtime has a lot of catching up to do.
- stcredzero 14y agoI would like to see Ulterior Reference Counting, or age-based hybrid GC for both. http://www.powershow.com/view/14655a-MGM5M/Ulterior_Reference_Counting_Fast_Garbage_Collection_without_a_Long_Wait_flash_ppt_presentation http://www.powershow.com/view/14655a-MGM5M/Ulterior_Referenc...
- bdcravens 14y agoFirst paragraph: "In Part 1, we looked at the code of two web services that implement an authentication web service. One written in Java, and one written in Go. It’s time to beat up on them a little bit." http://boundary.com/blog/2012/09/13/comparing-go-and-java/ http://boundary.com/blog/2012/09/13/comparing-go-and-java/
- masklinn 14y agoAnd the code repo: https://github.com/collinvandyck/go-and-java https://github.com/collinvandyck/go-and-java
- luriel 14y agoYour guess is probably quite accurate, is also probably mostly benchmarking the quality of the PostgreSQL drivers, the Go ones are good, but I'm sure there has been much more work in optimizing the Java ones.
- dchest 14y agoSome notes from looking at the Go code. I don't know how important are those for performance, more like style nits. Java version doesn't do type conversion: https://github.com/collinvandyck/go-and-java/blob/master/java/src/main/java/auth/UserDAO.java#L22 https://github.com/collinvandyck/go-and-java/blob/master/jav... rs.getString("id") rs.getBoolean("admin") Go version does conversion at runtime, as row.Scan() accepts interface values. Also, the usage of sql interface is not optimal (at least with regards to code length) -- since the query is for one row, why not use QueryRow instead of Query? Authorization header decoding is strange -- it creates new base64 decoder, then string reader, then decodes. Why not just use base64.StdEncoding.DecodeString() and get rid of a few lines of code and a few allocations? https://github.com/collinvandyck/go-and-java/blob/master/go/auth_resource.go#L57 https://github.com/collinvandyck/go-and-java/blob/master/go/... Similarly, JSON marshals into a newly allocated slice instead of creating a decoder and then marshaling directly into ResponseWriter. https://github.com/collinvandyck/go-and-java/blob/master/go/auth_resource.go#L35 https://github.com/collinvandyck/go-and-java/blob/master/go/... Constants for HTTP error codes, that are declared in net/http, for some reason are redeclared https://github.com/collinvandyck/go-and-java/blob/master/go/auth_resource.go#L12 https://github.com/collinvandyck/go-and-java/blob/master/go/... - - - I sometimes wonder why various benchmarks include colorful charts, but fail to include a few lines from a simple run of profiler. It's so easy to do, and yet nobody bothers to learn where the cycles are actually spent!
- luriel 14y agoAlso somebody in the gonuts list noted that both versions are using the database differently, if you fix the Go version to use prepared statements it doubles throughput.