I actually did a very similar test to this recently and got similar results (though mine was just between Go and Python)... in retrospect the reason is obvious: in python I was using python-cjson which is a heavily optimized C implementation of a json parser, while in Go I was using a 100% Go implementation.<p>In a certain way this shows nothing, since we all know C is fast. But in another way it convinced me that Python is actually fine for most of what I'm doing since it's easy to drop in to C for parts that need performance. And even more importantly there are often already already C libraries with python bindings that do the thing I'm looking for (ie parsing, numpy, etc).
The usual benchmark complaints: You're not really comparing language performance, because the Python version is using an optimized C library.<p>But isn't that the deeper point?<p>Program in something that lets you optimize easily (or use optimized libraries easily). That's a significant, real-world performance advantage.<p>While it is a virtual certainty that Go will get a fast JSON library, Python's broad, mature library support is very helpful.
This isn't a benchmark of the languages, but of the libraries that ship with them. That's fine, but be careful not to confuse that with a language benchmark.
Note that where you mean Python you pretty much mean this optimized C implementation: <a href="https://bitbucket.org/cmoyer/python-twitter/src/5bba928d8c12/simplejson/_speedups.c" rel="nofollow">https://bitbucket.org/cmoyer/python-twitter/src/5bba928d8c12...</a>
Given Go is a compiled language I am rather surprised at its low speed in this benchmark. I am not familiar enough with the language to take a look at the benchmark code, has anyone else done so?<p>I can't help wondering if the benchmark code is falling foul of Go's garbage collection which I understand from discussions here is somewhat less intelligent than Python's GC.
The Go program allocates a new item on every line instead of allocating a single struct and just passing a pointer into unmarshal, which would be way faster. There's some claim of "doing async style programming" but the Go code doesn't parellelize anything, so... not really a fair Go entry there. The input file is also not supplied.<p>edit: not to mention there are things like adding individual sums multiple times that suggest that the author didn't check the output to verify that all programs arrived at the same output...
I wrote the article because I write a lot of web applications which a vast majority of the request are JSON. I am about to do a lot of post analysis on JSON sent from the web browser so it is valuable for me to know how fast a language (library) JSON parser is. For highly concurrent webserver it is good to know how fast and efficient the JSON parser is since it will be doing a lot of concurrent parsing of JSON.
I understand the reasoning behind this benchmark, but the Python results aren't super relevant because the library is written in C.<p>What is interesting is the Dart/Go comparison. Dart's VM still doesn't have a lot of the optimizations that will ultimately be in there and it's keeping pace pretty well with Go's much more mature compiler (which are based on the Plan 9 compilers).
Can anyone talk about the state of the compiler in Go? How good/bad is the optimizer? That's not something you usually address early in language design.
I actually like dart and go more so than javascript. Javascript still has a leg up when it comes to libraries. If Go or Dart get a follow I would be happy to look into it.