Hacker News Reader

Comment by alberth | Hacker News Reader

Fantastic article; it paints a great picture of the journey taken & accomplished achieved.

My personal take is that the next major milestone for Erlang/Elixir will be a significantly more performance BEAM. Be it JIT or reworked Hipe.

Elixir (& Phoenix) brought a ton of interest from the Ruby community. The only remaining aspect that would keep a Ruby developer using Ruby is the perf vs Erlang. Today, for many raw perf task there isn’t a meaningful difference in speed (note I’m not taking scalability). As soon as the speed difference becomes meaningful, Erlang will get another wave of people.

View on HN

I work with Ruby and Elixir daily and Elixir is 10x faster. Phoenix recently added functionality to display response times in microseconds, partially as a showcase for its good performance. I dont doubt you can get more performance in C++ or something but its still lighting compared to Ruby.

I think this is a valid observation but the reason isn't necessarily that the Ruby language can't be used in a similar way, it's more so a death by 1000 cuts where Ruby encourages very small costs to be paid everywhere in return for a nicer programming experience.

The issue becomes hard to fix because all of these small costs add up but none will show as up a single bottleneck in practice, making profiling a blunt tool for this kind of performance problem. Elixir isn't immune to this either but the functional aspects of design do help keep some of these choices local to the code that chooses to trade some time or memory away for other conveniences.

An example I saw recently of this sort of adoption is map access, which is entirely okay if the trade-off is understood. I put in some time to show that much of the understanding of performance profile of the Access behavior gets colored by these expectations that the small things don't matter: https://lobste.rs/s/bctcke/performance_elixir_s_access_behav...

What Phoenix did to improve display response times that much?

Compiled views

https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2...

For one, they leveraged the speed of iolists on the BEAM very well.

https://www.bignerdranch.com/blog/elixir-and-io-lists-part-1...

Compiled routes https://elixirforum.com/t/phoenix-routing-is-fast/17782

Phoenix is faster than Rails, however Ruby is faster than Elixir when doing CPU intensive tasks. Like parsing text.

> Phoenix is faster than Rails, however Ruby is faster than Elixir when doing CPU intensive tasks. Like parsing text.

What is your definition of slow or fast?

For example with Elixir it was possible to generate 5,000x random 19 character codes in 3ms on a 5 year old i5 3.2ghz desktop workstation. I don't know how long it would take with Ruby but for such a text / CPU intensive task, I'm quite happy with the performance.

Also parsing templates with EEx is ridiculously fast, because it's not treated as a string.

      spec-builder git:(master)  ruby -e "require 'benchmark'; puts Benchmark.measure { 5_000.times { rand(36**19).to_s(36) } }"
    0.005459   0.000009   0.005468 (  0.005464)

I am at 5ms on a MacBook. Can you share your iex code?

Here's a couple of versions of the code: https://gist.github.com/nickjj/99ea84f460f41dae4139d0610ce80...

It would be interesting if you wanted to come up with a Ruby version that adheres to the random code spec which should be able to be determined from looking at the first 2 versions. It's basically only a subset of characters that can be used and the code should be output as XXXX-XXXX-XXXX-XXXX.

I personally use the 25ms version because I find it to be the best one if you factor in both speed and readability. I'm sure there's better ways but I'm only an Elixir beginner.

Also for the record I didn't write the 2nd or 3rd versions of that gist. I asked around in the community and that's what others have put together.

The "computer language benchmarks game" does not support this. Erlang is more than 2x faster than Ruby in cpu intensive tasks across their benchmarks.

fwiw

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Reply on news.ycombinator.com