Ah, I didn't realize that it wasn't complete. Nevertheless, I like the idea of having a fast and dirty option available. I bet we could build one in that retains compatibility with all features except nicely-formatted output and maybe error reporting that would be significantly faster.
As to stuff in standard.haml that's not in standard.rhtml, I was referring mostly to Haml constructs that simplify XHTML, like "!!!" and the comment character. I suppose these should really be considered part of Haml. I've just updated trunk to cache calls to Haml::Buffer#tabs. It increased speed a bit, but not a lot. Too bad. I didn't realize ERB has a different way of binding local args (guess I should be poking around that codebase a bit more :p). That's definitely something we want to change. There should be more attribute hashes in standard.haml. There are actually two right now, but that's not really representative. I should note that I have some ideas for how to improve speed further. The basic idea is that we're doing a lot more stuff as compile-time than we need to. We should be able to parse every tag and, ideally, most attributes and just cache that - the only thing that should need to be computed at runtime is scripts and dynamic attributes. Although it's just conceptual now, I'm going to actually implement this in 2.0. I'm not exactly sure when 1.7's going to be released... reasonably soon. Probably some time in mid-to-late June. There are still definitely some things I'd like to clean up (html2haml and css2sass need testing and bug-hunting), some outstanding bugs in the core (functional Sass recompilation logic when dealing with @import :-/) and maybe some features I'd still like to see added (tags with no inner whitespace are long overdue), but we're entering the home stretch. - Nathan Tom Bagby wrote: > I wasn't suggesting integrating the second patch, just proof of > concept that Haml can beat the default erb implementation (which isn't > well performing itself, as evidenced by just how much faster the pure > Ruby erubis implementation is). I implemented it specifically to > improve the performance of our application, which has very large views > with deeply nested sub-templates and was experiencing view related > bottlenecks. So it's also out there for anyone else who has an > immediate need to monkey around with making their views faster, in a > very use at your own risk, don't blame me when all your views stop > rendering and your server catches fire kind of way. > > I'm curious as to examples of what you mean by things that are "not > possible or easy to do in erb" that make the benchmarks lopsided? The > benchmarker uses standard.haml, right? Everything in there seems to > me to have a direct translation in rhtml. The other difference with > my fast & dirty engine (and another reason I wasn't suggesting it for > integration into trunk) is that I do nothing to fix whitespace > indentation in the output html. I suppose that's a fundamental > difference that will always have a perf impact on haml if it's not > turned off (though it can be made much faster than it is right now). > > I actually think the current benchmark task has some small biases > towards haml also. For instance, it doesn't do nested templates. > When you have a lot of subtemplates, the indentation level can get > quite high and ' ' * indentation, which is run on every single line, > takes longer. Multiply that by every single line in the file and it > adds up. Another bias is that it doesn't bind local variables. ERB > binds local variables by passing them as arguments to the compiled > rendering function, so they are bound and accessed as local variables, > which is cheap. Haml binds local variables by creating methods with > those variable names, so referring to them requires a method call, > which is substantially less cheap. Do you access local variables > enough times in a template for this to matter much? Probably not, but > who knows. Depends on the use case and it is definitely not > considered in the benchmark. I actually bring this up mostly because > I think haml should use the erb method of local binding, there are a > number of gotchas to the local variables as methods thing that I think > are being ignored. > > standard.haml also understresses using attribute hashes, there's only > one of them in the whole file, whereas in practice, these seem to be > much more frequent used. Hashes are relatively heavy, they are also > one of the only things I did not static-ize in my fast&dirty version > even when they only refer to literal string and numbers. I've now > realized how to do this at compile time based on some ideas I got from > Stefen Kaes's template optimizer for erb, I'll put up some code soon > showing how to do that. For now though, I think the effect of this > expensive feature is being undercounted. > > Btw, when is a likely release date for 1.7? > > -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 -~----------~----~----~----~------~----~------~--~---
