On 8 April 2015 at 20:32, tcha via Digitalmars-d <[email protected]> wrote: > On Wednesday, 8 April 2015 at 13:56:55 UTC, Sönke Ludwig wrote: >> >> The problem is that even the pull parser alone is relatively slow. Also, >> for some reason the linker reports unresolved symbols as soon as I build >> without the -debug flag... > > > Unfortunatelly I overlooked that I tested it with std_data_json v 0.12.0 > yesterday. > So tested it again today on master: > dmd and gdc failed to build in release > ldc2 works > > I tried it also with ParseJSONStream and made fork from original benchmark > with added tests (https://github.com/chalucha/benchmarks) so anyone can look > (and PR) > > Some results: > Ruby - 6.74s, 2106.2Mb > Go - 5.92s, 420.9Mb > D - 10.26s, 1322.5Mb > D Gdc - 24.76s, 926.1Mb > D Ldc - 26.31s, 925.0Mb > D new - debug - 14.98s, 1782.0Mb > D new Gdc - debug - 29.08s, 1663.9Mb > D new Ldc - 16.99s, 1663.0Mb > D new lazy - debug - 11.50s, 213.2Mb > D new lazy Gdc - debug - 13.66s, 206.1Mb > D new lazy Ldc - 3.59s, 205.4Mb > Python - 5.89s, 1063.4Mb > C++ Boost - 14.60s, 2884.8Mb > C++ Rapid - 0.80s, 678.9Mb > > > Also tried to dustmite the minimal failing version and here is a result: > http://pastebin.com/YjdvT3G4 > > It's my first use of it so I hope it can help to solve this problem. It > outputs less errors, but also compiles fine in debug and fails to link in > release.
Frankly, if we are not as fast (or elegant) as Python's json library, it should be thrown out back to the drawing board. Iain.
