Hampton and I have been discussing this, and we think we're going to hold off on integrating this into trunk until we start work on 1.8 (which will eventually become 2.0... I know, it's confusing, but after 2.0 it'll make sense). The primary reason being that getting faster is super-rad and makes for great announcements, and we'd love to be able to say we have a 40% speed increase in 1.7 and then /another/ huge increase in 2.0. We're also gearing up to release 1.7 pretty soon, so major engine changes/additions like this one are something we want to avoid for the time being. Rest assured it'll be the first thing we add to 1.8 after 1.7 is released.
Also, the Haml/ERB tests are a little skewed in favor of ERB, and tend to get more so as time goes by. Often stuff will be added to the Haml benchmarking template that's just not possible or not easy in ERB, which means Haml has to take time processing it and ERB just has roughly equivalent static content, and is thus faster. It might be a good idea to switch them both over to basic templates that just use tags and basic Ruby embedding. - Nathan Tom Bagby wrote: > 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 -~----------~----~----~----~------~----~------~--~---
