Matching ERB performance is definitely doable. I am not particularly
interested in the nicely formatted output aspect of Haml, it's the
clean/readable input files that I like. So I implemented a "fast &
dirty" version of the Haml engine. It dispenses with all the output
prettification and so ends up with mostly _erbout << "some string"
statements in the compiled templates. I also ditch the @haml_lineno
statements in favor of making the compiled template match up line for
line with the source haml file. I am currently using this modified
engine in a large project. Here is what the benchmarks look like in
my rails project:
user system total real
haml: 0.030000 0.000000 0.030000 ( 0.025950)
erb: 0.050000 0.000000 0.050000 ( 0.055813)
Haml/ERB: 0.46495
Twice as fast as ERB is good. Not erubis good, and we can do better,
but good. This is working with v1.5 of Haml. It works well on our
project which has a very large number of haml files, but I do not
guarantee correctness of features we don't actively use. Flattening
for instance, or filters besides plain, I don't really know if they
work or not. Unlike my other patch, using this engine dramatically
alters the format of the output because the whitespace is so
different. I need to think of an easy way to apply all of the
existing tests to the fast&dirty engine. Maybe just strip out all
white space when checking correctness.
I only got the current development version of Haml today to try out
adapting my patch into it. I've now adapted my fast&dirty engine to
work with it as well. The optimizing_engine.diff I just uploaded
contains modification to template.rb to switch to the optimizing
engine and the new optimizing.rb. To switch it on, add the line
Haml::Template.options[:optimize] = true
to your environment.rb. Or for benchmarking its easier to force it on
in template.rb.
The bad news is that performance is worse overall in the development
version of Haml. A fresh install of 1.5.2 gives Haml/ERB: 3.19276,
whereas 1.6.0 gives Haml/ERB: 3.50089. This deprovement is also
reflected in my fast&dirty engine. The one I adapted to work with
1.6.0 gives Haml/ERB: 0.846883. Still better than ERB I guess. My
hunch is that the new open_tag buffer method is slower because I
noticed some changes to it and it's one of the few functions I still
sometimes call in the dirty compiled template. But it could be many
things, I haven't looked into it.
I hope someone else might give this thing a try, I may try to fancy it
up to make it more useful/easy to setup to the general public, but at
least for now its been great for my personal use. One last note is
that this still doesn't fix the recompile on file-touch problem, spent
enough time moving the engine chunk over to 1.6 and now I feel lazy
and like maybe I should stop playing computer and have a beer.
-Tom
On May 4, 6:16 pm, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote:
> Most excellent! I'll work it in soon.
>
> As for working outside of Rails, I think the best thing to do would be
> to let the client handle that. It can add the _haml_render method to the
> instance object, which can then be called by the client. Haml::Template
> will handle this automatically for Rails.
>
> With this and the performance improvements that I'm planning for 2.0, we
> may even reach parity with ERB.
>
> - Nathan
>
> Tom Bagby wrote:
> > Hello. I've been using Haml for a while now. Our whole team loves
> > it, but it is very slow. And yes, this impacts overall app
> > performance, I have railsbench numbers that back me up, at least for
> > our particular use cases. Anyway, I've taken various approaches to
> > make it perform better. One thing I noticed and exploited is that the
> > HamlEngine evals its precompiled templates every single time, instead
> > of eval'ing once to create a render method like ActionView does.
>
> > I uploaded a patch that implements the ActiveView style "create a
> > method" approach as:
> > precompiled_methods_patch.diff
>
> > No idea how to link to that in a posting, I am new to Google groups.
> > The main flaw in this patch is that it does not look at compile times
> > to see if it should recompile a function for a touched file. This is
> > because I am working on a Rails project, not very concerned with using
> > Haml outside of Rails. So for my particular case I put logic in
> > template.rb to trigger a recompile which you don't see in this
> > abstracted out version. It needs to go somewhere else (I think?) for
> > the more general Haml-as-non-Rails-plugin case.
>
> > To demonstrate the impact this approach has, here is some output from
> > "rake benchmark":
>
> > Original:
> > ---------------------------------------------------
> > Benchmark: Haml vs. ERb
> > ---------------------------------------------------
> > user system total real
> > haml: 0.200000 0.010000 0.210000 ( 0.201928)
> > erb: 0.050000 0.000000 0.050000 ( 0.057552)
> > Haml/ERB: 3.50861
>
> > With method pre-eval:
> > ---------------------------------------------------
> > Benchmark: Haml vs. ERb
> > ---------------------------------------------------
> > user system total real
> > haml: 0.120000 0.000000 0.120000 ( 0.121438)
> > erb: 0.060000 0.000000 0.060000 ( 0.056232)
> > Haml/ERB: 2.15959
>
> > Thanks very much for Haml, it makes my views so pretty!
>
> > Hope this is useful,
> > Tom
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Haml" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---
