3 ms·

Do you respond like this when people talk about rewriting the hot loop part of their Python in a C extension, too? Ruby is, sadly, just slow. From my testing,

Do you respond like this when people talk about rewriting the hot loop part of their Python in a C extension, too? Ruby is, sadly, just slow. From my testing, Elixir/Phoenix is out of the gate 10x faster than Rails. Now, they saw a 30x speedup here, so I wouldn't be surprised if some of that came from a rewrite, but it's definitely not the case that all of it was.

falcolas 10y ago
Ruby is slow. But a database is orders of magnitude slower. So is a O(n) function when compared to a O(log(n)) function. So is transferring unoptimized files; or not serving static files over a CDN... There's a lot of optimizations which had a larger effect on the speedup than the choice of language.
- TylerE 10y ago
  The thing is that all your database communication is going through your language as well. Accessing a slow DB in elixir will be faster than accessing a slow DB in ruby.
- anorwell 10y ago
  I don't think "slow" is the real issue here, but rather concurrency models for IO-bound applications. The way Rails apps often work is that something like unicorn is used to maintain a pool of worker rails processes, which handle requests synchronously. That worker process will block while it waits for IO requests such as DB and HTTP requests. In this model, the worker memory footprint can end up being the problem, rather than speed of execution. Particularly in large Rails with many gems, loading the application can take up to hundreds of MB. This sets a fixed limit for the number of concurrent workers/requests. Rails doesn't _have_ to be used this way, but trying to write a concurrent-safe application in Ruby/Rails can be an uphill battle, because many gems do not work this way. Elixir does not have this constraint, because only a small part of the system (a single actor) is blocked waiting on I/O. This makes it much easier to support many more concurrent requests.

falcolas 10y ago

Ruby is slow. But a database is orders of magnitude slower. So is a O(n) function when compared to a O(log(n)) function. So is transferring unoptimized files; or not serving static files over a CDN... There's a lot of optimizations which had a larger effect on the speedup than the choice of language.

TylerE 10y ago
The thing is that all your database communication is going through your language as well. Accessing a slow DB in elixir will be faster than accessing a slow DB in ruby.
anorwell 10y ago
I don't think "slow" is the real issue here, but rather concurrency models for IO-bound applications. The way Rails apps often work is that something like unicorn is used to maintain a pool of worker rails processes, which handle requests synchronously. That worker process will block while it waits for IO requests such as DB and HTTP requests. In this model, the worker memory footprint can end up being the problem, rather than speed of execution. Particularly in large Rails with many gems, loading the application can take up to hundreds of MB. This sets a fixed limit for the number of concurrent workers/requests. Rails doesn't _have_ to be used this way, but trying to write a concurrent-safe application in Ruby/Rails can be an uphill battle, because many gems do not work this way. Elixir does not have this constraint, because only a small part of the system (a single actor) is blocked waiting on I/O. This makes it much easier to support many more concurrent requests.