4 ms·

>> slow as hell > A bit of an exaggeration. Actually, no. Last time I compared BEAM (Erlang) and something else, Erlang code that only parsed text data from a

by dozzie 10y ago

>> slow as hell > A bit of an exaggeration. Actually, no. Last time I compared BEAM (Erlang) and something else, Erlang code that only parsed text data from a file (CSV) was several times slower than Perl script that parsed that, built a structure, serialized it, and wrote back to a disk file (BerkeleyDB). > It's quite faster than Ruby (while keeping coder-friendly features such as auto-rollup to bignums). I doubt it, unless Ruby (MRI is what I think of) is an extremely poorly written interpreter. > If you use pattern-matching correctly, it is EXTREMELY fast at I/O or binary parsing. It's not. It's slow (I've seen it when comparing with other runtimes). It was never intended to be fast. It was always intended to be convenient and highly concurrent.

behrendtio 10y ago
> Actually, no. Last time I compared BEAM (Erlang) and something else, Erlang code that only parsed text data from a file (CSV) was several times slower than Perl script that parsed that, built a structure, serialized it, and wrote back to a disk file (BerkeleyDB). Yeah, Erlang/Elixir are both not very fast when it comes to stuff like file parsing. Jose, the creator of Elixir pointed that out several times before. But as mentioned before, web developers can greatly benefit from Elixir. > I doubt it, unless Ruby (MRI is what I think of) is an extremely poorly written interpreter. I wrote several things in both languages. CSV parsing is pretty much the same speed, again file handling in Erlang/Elixir. When it comes to real web apps, Elixir is usually faster by a factor of 10x when DBs are involved and 100x when it comes to plain rendering. > It's not. It's slow (I've seen it when comparing with other runtimes). It was never intended to be fast. It was always intended to be convenient and highly concurrent. As others have mentioned, depends on what you think is fast and in what areas. When it comes to web apps, Elixir is way faster than ruby, python and even node. Pattern matching, for instance used for router matching is very fast compared to the techniques used in ruby/python frameworks. Java, Go and several other languages are faster as Erlang/Elixir, of course. But Go is too low level for huge apps and Java is a whole different beast. Basically, Elixir is a nice middle ground to develop fast-enough web apps with high concurrency and easy scalability without sacrificing dev speed and dev fun.
- dozzie 10y ago
  > But as mentioned before, web developers can greatly benefit from Elixir. I'm not saying they wouldn't. I just object against calling Elixir "fast", because it's not. It's just used in the places where raw sequential processing speed is not what makes the difference. It only makes up for that loss because it doesn't degrade when the same procedure is executed many times simultaneously, which is very hard for anything that's not BEAM (or Go, so I hear). >> I doubt it, unless Ruby (MRI is what I think of) is an extremely poorly written interpreter. > I wrote several things in both languages. CSV parsing is pretty much the same speed, again file handling in Erlang/Elixir. Funny. I expected MRI to be as fast as Perl or Python. What you say means it's much slower. > When it comes to real web apps, Elixir is usually faster by a factor of 10x when DBs are involved and 100x when it comes to plain rendering. Unless I see how the comparison was arranged, I have trouble to believe that. I've seen BEAM being very slow for sequential workload, and there's no mechanism that would explain the speedup right off the bat, barring the possibility of comparison looking at apples and oranges (e.g. comparing raw SQL queries in Elixir to Django's ORM).
  - pmarreck 10y ago
    What's/where's your evidence? 1) The situation might have changed since you looked at this 2) The algorithm to do the work might have been suboptimal (for example, not taking advantage of pattern-matching, or using regex which everyone agrees is too slow in Erlang/Elixir) 3) for large files, there's some fiddly techniques that make things noticeably faster, see for example http://cloudless.studio/articles/12-elixir-vs-ruby-file-i-o-performance-updated http://cloudless.studio/articles/12-elixir-vs-ruby-file-i-o-...
    - dozzie 10y ago
      1) It might, but I doubt BEAM got rewritten in that extent. 2) Split on a comma is very hard to get suboptimal, especially when it was `string' module supplied by Erlang. 3) Half of those fiddly techniques will be very, very hard to use in Erlang (I understand that the thread is about Elixir, so you sort of assumed that I was talking about it even though I explicitly said that it was Erlang and BEAM code). Then, the load was on the CPU, not I/O. Reading the file upfront was not going to help.
rozap 10y ago
This was a great article on this sort of thing http://cloudless.studio/articles/12-elixir-vs-ruby-file-i-o-performance-updated http://cloudless.studio/articles/12-elixir-vs-ruby-file-i-o-... Tl;dr: Elixir is a bit faster than Ruby for straight up File IO if you really know what you're doing. Naive approaches in Elixir can lead to terrible performance. I'm a huge fan of Elixir, but eeking out better performance can require some tricks that aren't intuitive if you're new to the language. From personal experience (we're using Elixir at work) and we compared parsing a CSV in Elixir vs Scala, and the Elixir version was about 20% slower. However, for our use cases, we can more than make up for it by parellelizing processing downstream, ie: the csv parsing wasn't going to be the bottleneck anyway - other things, (which are easily parallelizable if you're running on BEAM) are the bottleneck, so BEAM gives us some nice things the JVM doesn't.

by dozzie 10y ago

behrendtio 10y ago

> Actually, no. Last time I compared BEAM (Erlang) and something else, Erlang code that only parsed text data from a file (CSV) was several times slower than Perl script that parsed that, built a structure, serialized it, and wrote back to a disk file (BerkeleyDB). Yeah, Erlang/Elixir are both not very fast when it comes to stuff like file parsing. Jose, the creator of Elixir pointed that out several times before. But as mentioned before, web developers can greatly benefit from Elixir. > I doubt it, unless Ruby (MRI is what I think of) is an extremely poorly written interpreter. I wrote several things in both languages. CSV parsing is pretty much the same speed, again file handling in Erlang/Elixir. When it comes to real web apps, Elixir is usually faster by a factor of 10x when DBs are involved and 100x when it comes to plain rendering. > It's not. It's slow (I've seen it when comparing with other runtimes). It was never intended to be fast. It was always intended to be convenient and highly concurrent. As others have mentioned, depends on what you think is fast and in what areas. When it comes to web apps, Elixir is way faster than ruby, python and even node. Pattern matching, for instance used for router matching is very fast compared to the techniques used in ruby/python frameworks. Java, Go and several other languages are faster as Erlang/Elixir, of course. But Go is too low level for huge apps and Java is a whole different beast. Basically, Elixir is a nice middle ground to develop fast-enough web apps with high concurrency and easy scalability without sacrificing dev speed and dev fun.

dozzie 10y ago
> But as mentioned before, web developers can greatly benefit from Elixir. I'm not saying they wouldn't. I just object against calling Elixir "fast", because it's not. It's just used in the places where raw sequential processing speed is not what makes the difference. It only makes up for that loss because it doesn't degrade when the same procedure is executed many times simultaneously, which is very hard for anything that's not BEAM (or Go, so I hear). >> I doubt it, unless Ruby (MRI is what I think of) is an extremely poorly written interpreter. > I wrote several things in both languages. CSV parsing is pretty much the same speed, again file handling in Erlang/Elixir. Funny. I expected MRI to be as fast as Perl or Python. What you say means it's much slower. > When it comes to real web apps, Elixir is usually faster by a factor of 10x when DBs are involved and 100x when it comes to plain rendering. Unless I see how the comparison was arranged, I have trouble to believe that. I've seen BEAM being very slow for sequential workload, and there's no mechanism that would explain the speedup right off the bat, barring the possibility of comparison looking at apples and oranges (e.g. comparing raw SQL queries in Elixir to Django's ORM).
- pmarreck 10y ago
  What's/where's your evidence? 1) The situation might have changed since you looked at this 2) The algorithm to do the work might have been suboptimal (for example, not taking advantage of pattern-matching, or using regex which everyone agrees is too slow in Erlang/Elixir) 3) for large files, there's some fiddly techniques that make things noticeably faster, see for example http://cloudless.studio/articles/12-elixir-vs-ruby-file-i-o-performance-updated http://cloudless.studio/articles/12-elixir-vs-ruby-file-i-o-...
  - dozzie 10y ago
    1) It might, but I doubt BEAM got rewritten in that extent. 2) Split on a comma is very hard to get suboptimal, especially when it was `string' module supplied by Erlang. 3) Half of those fiddly techniques will be very, very hard to use in Erlang (I understand that the thread is about Elixir, so you sort of assumed that I was talking about it even though I explicitly said that it was Erlang and BEAM code). Then, the load was on the CPU, not I/O. Reading the file upfront was not going to help.

rozap 10y ago

This was a great article on this sort of thing http://cloudless.studio/articles/12-elixir-vs-ruby-file-i-o-performance-updated http://cloudless.studio/articles/12-elixir-vs-ruby-file-i-o-... Tl;dr: Elixir is a bit faster than Ruby for straight up File IO if you really know what you're doing. Naive approaches in Elixir can lead to terrible performance. I'm a huge fan of Elixir, but eeking out better performance can require some tricks that aren't intuitive if you're new to the language. From personal experience (we're using Elixir at work) and we compared parsing a CSV in Elixir vs Scala, and the Elixir version was about 20% slower. However, for our use cases, we can more than make up for it by parellelizing processing downstream, ie: the csv parsing wasn't going to be the bottleneck anyway - other things, (which are easily parallelizable if you're running on BEAM) are the bottleneck, so BEAM gives us some nice things the JVM doesn't.