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."
> there's no point in pretending Ruby, compared to, say, Rust
Just the thought of comparing Rubys execution speed with Rust is pointless. They are completely different languages and has their own use cases, if you care about performance, Ruby is not it. I don't think the author intended to oppose that either
I had a similar conclusion about C++. C++ takes forever to compile, but C++ is truly insanely fast, its just the compilation process is insanely inefficient. Look at Go or even D (iirc with parallel compilation). It's a night and day difference. C++ is not slow, but its compilers sure as heck are.
Edit: Another honorable mention, look at Delphi in its prime, millions of lines of code, compiles in under 5 minutes.
Neat. It automates the same kind of optimization I’ve done with ERB before (pre-compiled templates in constants). It means I don’t have to teach people were and how to optimize ERB.
To get faster this, you need to get out your profiling tools and your notebook.
Builder::XmlMarkup and strings are significantly more flexible and have many optimization points. (E.g. not escaping numbers.) They have the potential to be an order of magnitude faster. But you’ll be using that notebook to diagram where everything goes.
5 comments
[ 0.18 ms ] story [ 28.0 ms ] threadThe 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."
Just the thought of comparing Rubys execution speed with Rust is pointless. They are completely different languages and has their own use cases, if you care about performance, Ruby is not it. I don't think the author intended to oppose that either
Edit: Another honorable mention, look at Delphi in its prime, millions of lines of code, compiles in under 5 minutes.
To get faster this, you need to get out your profiling tools and your notebook.
Builder::XmlMarkup and strings are significantly more flexible and have many optimization points. (E.g. not escaping numbers.) They have the potential to be an order of magnitude faster. But you’ll be using that notebook to diagram where everything goes.