5 ms·
HAML vs ERB vs SLIM in terms of render speed
- deleted 14y ago[deleted]
- judofyr 14y agoIt's called Haml and Slim, not HAML and SLIM. Are 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 https://github.com/stonean/slim#benchmarks Do all three template engines use automatic HTML escaping?
- urbanautomaton 14y agoYes, 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.
- judofyr 14y agoSlim defaults to ugly-mode: https://github.com/stonean/slim/blob/ae14457c596c963144810ced65ac9c275498bffd/lib/slim/engine.rb#L8 https://github.com/stonean/slim/blob/ae14457c596c963144810ce... Haml uses pretty-mode in development and ugly-mode in production.
- klaustopher 14y agoI 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
- klaustopher 14y agoMy bad, sorry ... I'm going to change it on the Github page, but I can't edit it here, sorry.
- theandym 14y agoHere are my results running it in production mode (RAILS_ENV=production rails server >/dev/null 2>/dev/null): ERB: 9.619 seconds Haml: 10.893 seconds Slim: 10.195 seconds Full details at https://gist.github.com/3906297 https://gist.github.com/3906297
- allr 14y agoDidn't know Slim was much faster than Haml, might worth it to switch, since the syntax is pretty similar anyway!
- lengarvey 14y agoOne of the biggest reasons to switch is that Slim supports streaming and Haml doesn't, or at least won't until the next major version. Sources: https://github.com/stonean/slim#slim https://github.com/stonean/slim#slim, https://github.com/haml/haml/issues/436 https://github.com/haml/haml/issues/436
- aoe 14y agoAre there any other pros/cons in switching to Slim? Other than the syntax of course.
- OffTheRails 14y agoI'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.
- calgaryeng 14y agoShould I be using Slim in all new projects at this point? Or are there any reasons for sticking with Haml?
- OffTheRails 14y agoI 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.
- nitrogen 14y agoI'm curious, why are the output sizes listed in the README different for each templating engine?
- klaustopher 14y agoI 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
- jashkenas 14y agoFor a bit of perspective, here's the same template being rendered with Underscore.js templates, under Node: https://gist.github.com/3905579 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.
- arthurschreiber 14y agoWell, that comparison is not exactly fair, is it? 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!
- klaustopher 14y agoI agree, If you would be using Express.js or something similar I think node would give you numbers that look more like the rails stuff. 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.
- jashkenas 14y agoOk -- you got it. I've updated the gist with the same template running through Express. https://gist.github.com/3905579 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.
- amikazmi 14y agoYou can make the benchmark with Rails Metal, or with Rack. If you want to compare non-blocking IO, use with eventmachine.
- zimbatm 14y agoYou 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.
- klaustopher 14y agoThat'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"
- dcu 14y agothis is unfair with haml, you have to turn on the ugly mode.
- aoe 14y agoI'm considering switching to Slim from Haml (not because of this benchmark, but the syntax). Are there any downsides to Slim that I should be aware of?
- cheald 14y agoIt's worth noting that Haml 3.2.0rc1 is some 15%-20% faster than the current master gem. I contributed the patches.