Yes, some configuration detail would be helpful. For instance, I can't find any custom Haml config, suggesting it's running with the defaults - in production mode this would mean that the output HTML is indented, while it wouldn't be in development or test. This has a noticeable performance effect, and it looks as though the same is true of Slim.
I was going with the defaults, and I was running it in development mode ... An issue on the page already pointed out, that the comparison to Slims ugly mode isn't really that fair.
But I just went with the out-of-the-box config, as do most Haml projects I've come across
I'd say speed and syntax are the main reasons. I've used both Haml and Slim over 5 or so projects and the jump doesn't feel all that significant. If you know Haml, you can pickup Slim within a couple of days at most.
I see no reason sticking with Haml at this point. They are easily interchanged and have tools available to convert one from the other. Do your own testing, of course, but Slim feels even more productive to code in than Haml. It just feels like the way forward.
I think it can be traced back to the pretty and ugly modes. Haml returns nicely indented code by default (at least in development, as I just learned), Slim uses ugly mode by default which doesn't add any whitespace or indentation
Whereas the original Ruby templates in the original benchmarking do about 40-50 requests per second, with "c=1", the JavaScript templates do 1,732 requests per second on my laptop.
While the rails benchmark tries to compare different template engines in the same language, framework, and with blocking IO, you're comparing these results to rendering under "pure" Node.js (no framework that slows you down) with non-blocking IO.
Don't take this the wrong way, tho, I'm absolutely blown away by your numbers!
Yeah I'm pretty sure the rails benchmark is IO-bound. If that is the case it is surprising there is any noticeable difference at all between the three different Ruby template engines.
Running the same benchmark against DocPad a node.js framework, getting good speeds too (1147req/s). Benchmark: https://gist.github.com/3906050
Worth noting the tests are being run against a local copy of - http://docpad-kitchensink.herokuapp.com/ - which does a lot more stuff than the basic haml rendering.
This is not very useful "perspective" - as far as I can see this benchmark is run using "rails s" which boots up the WEBrick server - I seriously doubt you'd find anyone using that in production! Maybe it's best to leave this as a Rails apple-to-apples comparison...
I said that the results come from running webrick, I want to give the other servers a try. But in my opinion the web server shouldn't have anything to do with the render speeds of the template language. That's why I'd love to eliminate it altogether
I'd even say that the biggest contributor to this difference is the non-blocking nature of Node. Using e.g. EventMachine would probably close the Gap between Node and Ruby even more.
You would have less moving parts if you used Tilt+(ERB|Haml|Slim).
Because the test is done on top of webrick, the document size probably matters more than we think. You could also give a baseline by returning a raw string to show the framework overhead.
That's a good idea, I think I will be going that route. Then I wouldn't have to deal with any server differences, etc ...
But I think if I do the comparison without a full web stack, people will be like "Yeah, in this lab scenario ... But the real world looks different because of this and that in rails"
32 comments
[ 3.5 ms ] story [ 87.6 ms ] threadAre you running the server in production mode?
Slim already has a set of benchmarks that compares it to Haml and ERB in various settings: https://github.com/stonean/slim#benchmarks
Do all three template engines use automatic HTML escaping?
Haml uses pretty-mode in development and ugly-mode in production.
But I just went with the out-of-the-box config, as do most Haml projects I've come across
ERB: 9.619 seconds
Haml: 10.893 seconds
Slim: 10.195 seconds
Full details at https://gist.github.com/3906297
Sources: https://github.com/stonean/slim#slim, https://github.com/haml/haml/issues/436
https://gist.github.com/3905579
Whereas the original Ruby templates in the original benchmarking do about 40-50 requests per second, with "c=1", the JavaScript templates do 1,732 requests per second on my laptop.
With "c=10", they do 2,370 requests per second.
While the rails benchmark tries to compare different template engines in the same language, framework, and with blocking IO, you're comparing these results to rendering under "pure" Node.js (no framework that slows you down) with non-blocking IO.
Don't take this the wrong way, tho, I'm absolutely blown away by your numbers!
But I'm really interested in eliminating as much of the framework as possible to get more comparable numbers even to other platforms.
I'm also sort of blown away by the throughput node allows you.
https://gist.github.com/3905579
Take note that the margin of variance on these numbers is several hundred, so don't read too much into small shifts ... but:
With Express, and "c=1", I get 1,876 requests per second.
With Express, and "c=10", I get 2,730 requests per second.
There isn't meaningful overhead imposed by Express for this particular simple template rendering.
Worth noting the tests are being run against a local copy of - http://docpad-kitchensink.herokuapp.com/ - which does a lot more stuff than the basic haml rendering.
https://gist.github.com/3906254
Because the test is done on top of webrick, the document size probably matters more than we think. You could also give a baseline by returning a raw string to show the framework overhead.
But I think if I do the comparison without a full web stack, people will be like "Yeah, in this lab scenario ... But the real world looks different because of this and that in rails"
Are there any downsides to Slim that I should be aware of?