HAML vs ERB vs SLIM in terms of render speed | Hacker News Reader

HAML vs ERB vs SLIM in terms of render speed

github.com

30 pointsklaustopher31 comments

For a bit of perspective, here's the same template being rendered with Underscore.js templates, under Node:

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.

Well, 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!

I 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.

Ok -- you got it. I've updated the gist with the same template running through Express.

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.

You can make the benchmark with Rails Metal, or with Rack. If you want to compare non-blocking IO, use with eventmachine.

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...

You'll find people saying the same thing about express or even node in general.

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

On my system (only tested with c=1) in a comparable minimalist setup, ruby does 1477.48 and node 2541.61. Not too bad but still 2 times slower.

https://gist.github.com/3906254

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.

It'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

Do all three template engines use automatic HTML escaping?

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.

Slim defaults to ugly-mode: https://github.com/stonean/slim/blob/ae14457c596c963144810ce...

Haml uses pretty-mode in development and ugly-mode in production.

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

My bad, sorry ... I'm going to change it on the Github page, but I can't edit it here, sorry.

Here 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

It's worth noting that Haml 3.2.0rc1 is some 15%-20% faster than the current master gem. I contributed the patches.

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"

I'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?

Didn't know Slim was much faster than Haml, might worth it to switch, since the syntax is pretty similar anyway!

One 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/haml/haml/issues/436

Are there any other pros/cons in switching to Slim? Other than the syntax of course.

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.

Should I be using Slim in all new projects at this point? Or are there any reasons for sticking with Haml?

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'm curious, why are the output sizes listed in the README different for each templating engine?

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

this is unfair with haml, you have to turn on the ugly mode.

Reply on news.ycombinator.com