HAML: RoR's new templating engine

Rails
61

A native version would most likely be a unix-only Gem that can
optionally be installed to speed up certain string-manipulations
(especially in the pre-compile) stage.

However, also this weekend, I was working on the code-base for the
upcoming 0.3 release and added caching (via pre-compiled buffering) to
the engine. I was able to achieve a 50% speedup. My benchmarks on v.2
that take 0.5 seconds now take 0.22 seconds (results obviously may
vary).

This puts us much closer to where we want to be.

That being said. I agree with you. All of my production apps seem
zippy enough. I really don’t notice any slow-downs at all. However,
that being said, I still think its important to really work on this
and keep the code as stable and fast as possible.

-hampton.

62

Just a comment on a C compiler. It seems like optimizing that close
to bare metal will introduce portability issues. In any case, a
different approach would be to introduce an optimizer much as Stephan
Kaes has shown for Erb. The idea is that you do some semantic
evaluation of the code looking for things like loop-invariants,
common sub-expressions, and expensive evaluations that might be
linearized.

I’m still not sure rendering is that big a deal. It’s very difficult
to tell where the components divide out, but RailsBench does a pretty
good job of telling you – is it clear that everyone is suffering
from templating engine overhead? Compiling to C just seems like a big
hammer.