Feels like a misleading headline. The author created another templating language alternative to ERB, found that it was slower than ERB, then optimise it until it was roundabout as fast as ERB given a relatively simple template.
The author then appears to draw the wrong conclusion:
> What I find most interesting about the changes I’ve made to code generation in P2, is that the currently compiled code is more than twice as fast as it was when P2 first came out, which just goes to show than in fact Ruby is not slow, it is actually quite fast, you just need to know how to write fast code! (And I guess this is true for any programming language.)
I love Ruby, but it is still a slow language on most benchmarks. That's ok. For most webapps, the bottleneck is not execution-time performance, it's the speed and joy of writing the code. Functionality that never got built because it was too annoying to build is infinitely slow. But there's no point in pretending Ruby, compared to, say, Rust, isn't a slow-as-molasses execution environment. It is. It's ok. It's optimised for developer happiness, not speed.
And yes, even so, you can write slow Ruby code and fast Ruby code. Again, which one makes sense is contextual. But it doesn't make the point that "Ruby isn't slow."
barrkel•4h ago
Ruby is slow, but it is however faster than Python last I checked, with like for like code.
Python gives you other interesting ways of going fast (a lot of high performance plugins for numerics, Cython, and so on), while Ruby is a higher level more expressive language IMO, so you have more ways to shoot yourself in the foot more powerfully.
Asmod4n•3h ago
Depends how you use it, just last week I’ve hit 40 nanoseconds unpacking a 8 megabyte msgpack array and accessing one of its values in a hash.
As long as you only use ruby as glue code for c(++) extensions it’s pretty fast.
norman784•3h ago
AFAIK with the latest JIT in some contexts pure Ruby can be faster than using C libraries, just because the VM can be better optimized and there is no overhead in moving data between the two realms.
I don't recall exactly where I read it, but I think was a while ago when they announced one of the newest JIT engines.
ciconia•3h ago
Hi, author here. Taking your argument to its logical conclusion we can say that it doesn't matter if your Ruby code is slower or faster because it's Ruby, we know it's "slow-as-molasses", we only care about developer happiness, and anyways we're I/O-bound, so it doesn't really matter how our code performs...
But in my experience it does. I've built platforms in Ruby that handle north of 1K reqs/sec with bursts of 10K reqs/sec on moderate hardware, without needing to setup a whole cluster of machines that crunch on poorly-performing code.
From my experience, getting the average execution time per render from say 0.1ms to 0.01ms, and especially reducing allocations and GC pressure has a big effect on 99% percentiles, and consequently on the cost of compute.
Saying because we use Ruby we don't care if it's slow or not is in a way dismissing it as a viable platform for writing reliable software (because performance is part of reliability).
To me, you can use Ruby to create systems that have very good performance characteristics, and still benefit from developer happiness. The two are not contradictory.
makeitdouble•3h ago
> Taking your argument to its logical conclusion we can say that it doesn't matter if your Ruby code is slower or faster because it's Ruby, we know it's "slow-as-molasses", we only care about developer happiness, and anyways we're I/O-bound, so it doesn't really matter how our code performs...
Not OP, but to a point I think this is pretty much true...
We currently have decent performance so it works out well for most use cases, but if Ruby were to be slower, we could probably cover that issue with infra, caching or other means. As we already do in many cases.
It would be a pain point, but in comparison increasing developer happiness or the whole product dev experience is IMHO a lot harder. Perfs would need to be abysmally bad to change that balance.
Lio•1h ago
Yep, I agree with this.
Jean Boussier wrote this execellent examination of CPU bound Rails application and why making use of multi-processes is probably a good idea.
Even if you're not using CPU bound it's still daft to leave performance on the table you don't need to.
For the most part if something is a bit slower than it needs to be it still makes more sense to take the obvious bottle necks out before you rewrite the whole system in another language. Especially with YJIT and forcoming ZJIT availible.
swombat•4h ago
The author then appears to draw the wrong conclusion:
> What I find most interesting about the changes I’ve made to code generation in P2, is that the currently compiled code is more than twice as fast as it was when P2 first came out, which just goes to show than in fact Ruby is not slow, it is actually quite fast, you just need to know how to write fast code! (And I guess this is true for any programming language.)
I love Ruby, but it is still a slow language on most benchmarks. That's ok. For most webapps, the bottleneck is not execution-time performance, it's the speed and joy of writing the code. Functionality that never got built because it was too annoying to build is infinitely slow. But there's no point in pretending Ruby, compared to, say, Rust, isn't a slow-as-molasses execution environment. It is. It's ok. It's optimised for developer happiness, not speed.
And yes, even so, you can write slow Ruby code and fast Ruby code. Again, which one makes sense is contextual. But it doesn't make the point that "Ruby isn't slow."
barrkel•4h ago
Python gives you other interesting ways of going fast (a lot of high performance plugins for numerics, Cython, and so on), while Ruby is a higher level more expressive language IMO, so you have more ways to shoot yourself in the foot more powerfully.
Asmod4n•3h ago
As long as you only use ruby as glue code for c(++) extensions it’s pretty fast.
norman784•3h ago
I don't recall exactly where I read it, but I think was a while ago when they announced one of the newest JIT engines.
ciconia•3h ago
But in my experience it does. I've built platforms in Ruby that handle north of 1K reqs/sec with bursts of 10K reqs/sec on moderate hardware, without needing to setup a whole cluster of machines that crunch on poorly-performing code.
From my experience, getting the average execution time per render from say 0.1ms to 0.01ms, and especially reducing allocations and GC pressure has a big effect on 99% percentiles, and consequently on the cost of compute.
Saying because we use Ruby we don't care if it's slow or not is in a way dismissing it as a viable platform for writing reliable software (because performance is part of reliability).
To me, you can use Ruby to create systems that have very good performance characteristics, and still benefit from developer happiness. The two are not contradictory.
makeitdouble•3h ago
Not OP, but to a point I think this is pretty much true...
We currently have decent performance so it works out well for most use cases, but if Ruby were to be slower, we could probably cover that issue with infra, caching or other means. As we already do in many cases.
It would be a pain point, but in comparison increasing developer happiness or the whole product dev experience is IMHO a lot harder. Perfs would need to be abysmally bad to change that balance.
Lio•1h ago
Jean Boussier wrote this execellent examination of CPU bound Rails application and why making use of multi-processes is probably a good idea.
Even if you're not using CPU bound it's still daft to leave performance on the table you don't need to.
For the most part if something is a bit slower than it needs to be it still makes more sense to take the obvious bottle necks out before you rewrite the whole system in another language. Especially with YJIT and forcoming ZJIT availible.
1. https://byroot.github.io/ruby/performance/2025/01/23/the-myt...