On: Fastest JSON parser in the world is a D project?

[wfunction]

> Yep, that's right. stdx.data.json's pull parser finally beats the dynamic languages with native efficiency.

'dynamic' is the key word here. The title is misleading.

[masklinn → wfunction]

You may want to read past that part. The author was just pointing out that only around DMD 2.067 (that's March 2015 or later) did D finally get a JSON library which did genuinely better than those in dynamic language stdlibs, which hadn't been the case beforehand (the stdlib DMD 2.067 rivaling but not being better than Python's json on the author's system).

That's setup for the reveal of "fast" which not only does better than dynamic language stdlibs and than the previous fastest D library but does better than any other JSON parser.

The point of the historical recap is how fast things improved for the D ecosystem: in 7 months the best-case option went from parsing JSON 2~3 times slower than Ruby to parsing it in half the time of RapidJSON, a 2 orders of magnitude improvement in speed.

[vamega → wfunction]

This post is about the fast project, which is claimed to beat RapidJson, a very fast C++ json parser.

[easytiger → vamega]

If it was implemented in c++ using identical algorithms it would be no slower.

[fauigerzigerk → easytiger]

That's hard to know. It's always possible that one compiler generates faster code than another one for the same algorithm.

I wouldn't be surprised if most of the speed difference was down to correctness checks though.

[easytiger → fauigerzigerk]

There are full threads on why this impl is faster. It's cheating

[jonnybgood → wfunction]

https://github.com/kostya/benchmarks#json

[syllogism → wfunction]

The fast Python json libraries are all C extensions, though. The only "dynamic" thing they have to do is create the actual Python objects when they're done.

[illumen → syllogism]

Most of python code that takes time has C/asm extensions. It's part of the 'glue code' nature of python. Right tool for the job and all that.