3 ms·
I like the benchmark and I appreciate the work that was put into, but Erlang is missing again. If you don't even consider Erlang you won't miss it. But if you
by stesch 13y ago
I like the benchmark and I appreciate the work that was put into, but Erlang is missing again.
If you don't even consider Erlang you won't miss it. But if you know it has some strengths for this kind of job and you don't mind the syntax, you'd like to see it compared to other solutions.
- agilebyte 13y agoI have heard that string operations (and I thus suspect JSON parsing too) is slower on Erlang. Maybe it is not included as it was not built for raw speed but rather stability, hotswapping code etc?
- stesch 13y agoErlang was included in round 6 of the benchmark.
- agilebyte 13y agoAh thanks, under Cowboy and Elli.
- rdtsc 13y agoString equivalents in Erlang are binaries quite often. There are also iolists, those are pretty efficient. This blog post describes this in a lot more depth: http://jlouisramblings.blogspot.com/2009/01/common-erlang-misconceptions.html http://jlouisramblings.blogspot.com/2009/01/common-erlang-mi...
- kainsavage 13y agoI just posted another response to this - we had some trouble with the package manager for Erlang after round 6. Additionally, I had been working on improvements for the suite specifically (better logging/reporting, etc) and did not get a chance to resolve the Erlang problems. Rest assured, "get erlang running again" tops my 'todo' list for round 9.
- SkyMarshal 13y agoWhile we're at it, any chance of you guys including some Elixir frameworks too? I'd love how to Elixir performance is starting to take shape vs native Erlang frameworks.
- brickcap 13y agoAs far as I understand exlir compiles into erlang code. So there should be no performance difference.
- SkyMarshal 13y agoThat's never been the case with other languages like Scala or Clojure that target another VM bytecode, definitely not an assumption you can just make.