Sorry, about overlooking things in the string literal parsing.
prerender_static_tags.diff is probably the last in my series of
optimizations in this vein, heh. open_tag is by far the most
expensive buffer operation. This patch takes tags which have no
dynamic content, and prerenders them as text.
Before: Haml/ERB: 1.97723
After: Haml/ERB: 1.7577
To things you should probably note/decide about in the diff. I made
one_liner? a class method on Buffer so I could call it from Engine. I
cut & pasted build_attributes from Buffer to Engine to use in the
prerender. It has instance variables that make it unfriendly to being
a class method, I leave it to you how best to share this functionality
without repeating.
I have two unrelated questions/suggestions:
1) In the TODO, it mentions wanting to:
> Get rid of line number counting and make template lines one-to-one with
> precompiled lines
I've benchmarked related to this, and it doesn't impact performance
much. Is that the only reason to get rid of this? My other
suggestion is that making a line for line matchup is tedious and error
prone. You've mentioned other reasons for keeping around the
precompiled templates. If those were always there, you could stub out
the @haml_lineno lines as comments, [EMAIL PROTECTED], you could then use
the same search strategy as for finding line no's of compile errors
with no impact on the runtime.
2) What's the intended use of @tabulation in Buffer? It seems like
helpers can set it to do custom tabbing? A lot of time is spent
tabulating what could just be static pre-indented strings. Treating
extra tabulation as a special case is very fruitful for speeding
things up, so I just want to make sure my assumptions about why it's
used/useful are right.
-Tom
On Jun 2, 3:39 pm, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote:
> Yes, you're right, the parser didn't realize that #{} wasn't normal
> string content. This is now fixed.
>
> - Nathan
>
> Robin wrote:
> > I suspect this patch has broken my code. I do the following a lot:
>
> > %span{:id => "more_info_#{store_item_type[:item_type_id]}"}
>
> > With this new patch, the #{} content is not being evaluated at all and
> > has broken many of my pages.
>
> > On Jun 2, 6:45 am, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote:
>
> >> Alright, I've modified this a bit and added it to trunk. Thanks a bunch.
>
> >> - Nathan
>
> >> Tom Bagby wrote:
>
> >>> parsing_literal_hashes.diff handles this. It touches more things than
> >>> I originally intended because of finding some bugs as I went.
>
> >>> For example:
>
> >>> - Attribute hashes built internally all assume that keys are symbols.
> >>> This was causing weird cases of spitting out tags with multiple class
> >>> or id attributes. I chose to start forcing keys to strings. The
> >>> alternative of interning everything is also an option.
>
> >>> - The object ref syntax was not (still isn't quite) consistent in how
> >>> it overrides existing classes or id's. Have tried to fix this to an
> >>> extent.
>
> >>> - I'm not sure how this test is supposed to work:
> >>> assert_equal("<p escaped=\"q'uo"te\">\n</p>\n",
> >>> render("%p{ :escaped => 'q\\'uo\"te'}", :attr_wrapper => '"'))
>
> >>> Since the actual test code is in double quotes, the double backslash
> >>> turns into a single backslash, but quoting the single quote should be
> >>> left in when we actually eval this since single quotes don't do escape
> >>> sequences, which means that the asserted result should have a
> >>> backslash in there, so ... I changed it to what I thought it should be
> >>> but I'm unclear on what this is even testing.
>
> >>> As per recent comments about patching protocol, maybe this is a bunch
> >>> of stuff in one diff, but it's all fallout from doing the literal
> >>> hashes thing and then making tests not fail. Can break it up into
> >>> steps if necessary.
>
> >>> -Tom
>
> >>> On May 30, 8:55 pm, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote:
>
> >>>> Very good. Committed.
>
> >>>> I've also been meaning to get around to making string-only attributes
> >>>> parsed at compile-time. That'll also be useful for allowing people using
> >>>> :suppress_eval to have attributes.
>
> >>>> - Nathan
>
> >>>> Tom Bagby wrote:
>
> >>>>> Uploaded preparse_class_ids.diff
>
> >>>>> Pretty straightforward, moves processing of class and id strings to
> >>>>> engine and not buffer. Nice little perf boost results:
>
> >>>>> Before: Haml/ERB: 2.23403
> >>>>> After: Haml/ERB: 1.96521
>
> >>>>> -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
-~----------~----~----~----~------~----~------~--~---
