minhajuddin
Crude JSON parsing benchmarks for Elixir, Ruby, Golang
https://github.com/minhajuddin/benchmark-large-json-parsing
Benchmark large json parsing
A few crude benchmarks for Elixir, Golang and Ruby
Processor Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
OS: Ubuntu 16.04
10mb.json
Golang [jq]
$ time jq '.' data/10mb.json > /dev/null
real 0m0.567s
user 0m0.551s
sys 0m0.016s
Elixir
Time taken [Poison]: 1218.831ms
Time taken [Jason]: 508.461ms
Ruby
time ruby app.rb
real 0m0.220s
user 0m0.203s
sys 0m0.017s
100mb.json (sf-city-lots-json/citylots.json at master · zemirco/sf-city-lots-json · GitHub)
Golang [jq]
$ time jq '.' data/citylots.json > /dev/null
real 0m14.436s
user 0m13.992s
sys 0m0.420s
Elixir
Time taken [Poison]: 32_640.87ms
Time taken [Jason]: 11_602.128ms
Ruby
$ time ruby app.rb
real 0m4.738s
user 0m4.498s
sys 0m0.240s
Most Liked
michalmuskala
michalmuskala
The Ruby parser is implemented in C, so it’s more like comparing C to Elixir. Obviously C is going to be faster
We’re not doing that bad actually. It would be interesting to compare with Jason compiled with HiPE. In my benchmarks this makes it at least twice as fast.
The data is also quite different from what you’d face in a regular HTTP app - the JSON is pretty-printed, most JSON flying on the wire is not. This can have significant difference in the actual performance. Depending on what you want to learn from this, it can be important.
OvermindDL1
Let’s have some fun, here is how they compare to C++/rapidjson:
# Golang
$ time jq '.' data/10mb.json > /dev/null
real 0m0.607s
user 0m0.603s
sys 0m0.004s
$ time jq '.' data/citylots.json > /dev/null
real 0m14.348s
user 0m13.839s
sys 0m0.504s
# Elixir
## 10mb.json
Time taken [Jason]: 521.655ms
Time taken [Poison]: 1358.531ms
## citylots.json
Time taken [Jason]: 12224.44ms
Time taken [Poison]: 33350.239ms
# Ruby
## 10mb.json
$ time ruby app.rb
real 0m0.350s
user 0m0.250s
sys 0m0.020s
## citylots.json
$ time ruby app.rb
real 0m5.632s
user 0m5.393s
sys 0m0.236s
# C++
$ time ./rapidjson-testing < ../../benchmark-large-json-parsing/data/10mb.json
real 0m0.035s
user 0m0.034s
sys 0m0.000s
$ time ./rapidjson-testing < ../../benchmark-large-json-parsing/data/citylots.json
real 0m0.531s
user 0m0.503s
sys 0m0.028s
Admittedly this benchmark is flawed because jq is outputting to stdout and elixir/ruby/C++ are just kind of blackholing the data after it is parsed, so jq/go is artificially limited here. In addition the elixir version is actually instancing a tree to hold the whole structure, which is wasted work as well (unsure about ruby). The C++ version is fully parsing and performing callbacks for every parse (standard sax parsing).
I can PR the C++ one in it if you want, it only needs the normal C++ compiler and cmake installed, nothing else needed (not even rapidjson, it acquires it itself). ![]()
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance










