I'm happy that I received so much feedbacks, thank you all!
However I see a few comments that missed a bit the point, and this is probably my fault because I did not specified some very important thing:
Once you substitute not just an hello world template, but a few templates N times (since you have N comments in the page), the performance starts to be so slow you can't serve more than about 10 requests per second, just because template substitution is so damn slow if you don't preload templates, and the obvious way to do it is calling :erb (you see this in all the Sinatra code around, in the examples, and so forth).
10 requests per second instead of the 1000 you get even with 'N' includes if you perform a faster substitution, or if you preload the templates, or using any other trick, is a huge difference.
I don't get your article. You're yak shaving, bothering with meaningless issues.
In case you want raw rendering speed, you don't choose PHP or Ruby or any other high-level language. You go for straight C/C++ instead -- that's what companies like Google do; that's what Adobe did for Photoshop.com, that's what Yahoo does too for various web services they provide.
We pick PHP, Ruby, Python or whatever because there's a point of diminishing returns. For our apps 10 extra requests per second do NOT matter.
But 1000 reqs per second do matter, but for a real world app, not for a dumb hello world that doesn't do anything -- and even that may be insufficient, as depending on your use-case you may need 100000 requests per second out of a single server.
AND performance on the web == page rendering time, not requests per second. It gets pretty damn hard to have 300ms page loads, and IMHO this is where template rendering could make a difference, but again, not that much.
"you don't choose PHP or Ruby or any other high-level language".
Why? There is no technological limit, the template substitution should be fast, with minor coding effort it can be fast. It's just lame code. We are not speaking of algorithmic code.
Probably language speed is not involved at all, it is just as lame as the framework reloading the template at every page view. And even more lame than that given that even my test loading the template every time was faster.
So, how much do you spend on web servers (not including databases) per week? You could fix Ruby templating, or just multiply that by 10. Or you can try to overhaul the templating. It's a boring problem.
Databases are much more interesting. You simply can't scale databases up trivially. A N times linear improvement in the code (due to, say, caching) means you don't have to throw N^2 servers (if that's how your database scales) at the problem.
Linear load reductions have superlinear cost reductions for things like databases. Linear load reductions have linear cost reductions for web servers. This is why people don't care so much.
Though yes, it would be nice to see Ruby templating a little bit faster.
However I see a few comments that missed a bit the point, and this is probably my fault because I did not specified some very important thing:
Once you substitute not just an hello world template, but a few templates N times (since you have N comments in the page), the performance starts to be so slow you can't serve more than about 10 requests per second, just because template substitution is so damn slow if you don't preload templates, and the obvious way to do it is calling :erb (you see this in all the Sinatra code around, in the examples, and so forth).
10 requests per second instead of the 1000 you get even with 'N' includes if you perform a faster substitution, or if you preload the templates, or using any other trick, is a huge difference.