List Info

Thread: Re: HAML Performance




Re: HAML Performance
country flaguser name
United States
2007-11-05 12:27:03
I wouldn't expect this to work well for Haml performance. 
We already
use the << operator for all the string concats.  These
add to the
existing string in place.  see http://ruby.abou
t.com/b/a/000036.htm
about the difference between + and << operators.  We
don't do a lot of
modification of the component strings, many are shoved in
as-is,
script output might go through a regex substitution before
concat.
This is not really the kind of situation that ropes
improves, I would
expect spending time  in the library being too clever would
degrade
performance as in Hampton's benchmark.

I've racked my brain and see few performance gains left to
be made
without turning off pretty indentation.  Turning off the
regexen that
pretty up script output and not special casing "one
liner" script
output are the two biggest fixable time sinks right now. 
The bad part
is that both unlike previous optimizations, these actually
change the
output.  Makes testing for correctness harder and in the one
liner
case could subtly change how output renders in the browser
thanks to
inconsistent treatment of new line white space.

So, I personally use a faster Haml based on those two
changes, but due
to time constraints from day job/life, haven't figured out
how to
overcome the other two issues as far as making such a thing
an option
available in standard Haml.

-Tom


On Nov 4, 8:47 am, David Richards <dricha...showcase60.com> wrote:
> I've forwarded this thread to Eric, who wrote the ropes
gems, to see
> what ideas he could throw to this discussion.  Sorry
I'm not any more
> informed than this.
>
> David
>
> On Nov 3, 11:59 am, Hampton <hcat...gmail.com> wrote:
>
> > So, I quickly grabbed a copy of the
"rope" library.https://rubyforg
e.org/projects/rope/
>
> > I was able to get *most* of the tests passing...
and most importantly
> > I got the benchmarks running. Basically I replaced
the Buffer's
> > internal string (lots of appends) with the
"rope" library.
>
> > Unfortunately, instead of a speed boost.... we are
2x slower.
>
> > I might be doing something wrong in there though.
>
> > Check out the code athttp
://svn.hamptoncatlin.com/haml/branches/ropey
>
> > I'm going to run profiler on it and see what I can
figure out. Anyone
> > else want to make a stab? Hackers--- start your
engines!
>
> > -hampton.
>
> > On 11/3/07, Hampton <hcat...gmail.com> wrote:
>
> > > David-
>
> > > Yeah, we'd definitely be interested in
learning more about that.
>
> > > Anything to make our baby faster!
>
> > > Have any good links on the subject?
>
> > > -hampton.
>
> > > On 11/3/07, David Richards <dricha...showcase60.com> wrote:
>
> > > > First, the disclaimer.  I haven't used
HAML or Sass in about 2
> > > > projects.  It looks like you guys have
done a lot to make things zippy
> > > > in the last little while.
>
> > > > Here's another 2 cents to add to the
discussion.  I'm at RubyConf
> > > > right now, and the discussion on ropes
really was interesting for this
> > > > kind of problem.  They were talking
about Erb as a good place to apply
> > > > ropes, for performance reasons.  Is this
something you'd be interested
> > > > in applying?
>
> > > > The basic idea is that a string can be
stored as a tree internally.
> > > > Operations like parsing, appending,
finding, etc. are much faster with
> > > > ropes than with strings.
>
> > > > The Confreaks guys have captured
RubyConf on video, so anyone should
> > > > be able to see the whole ropes
discussion soon.  There were also some
> > > > other base data types discussed in the
room at the conference that
> > > > could be useful.
>
> > > > Anyway, this looks like it'd be a
productive conversation to have.
>
> > > > Cheers,
>
> > > > David


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Haml" group.
To post to this group, send email to hamlgooglegroups.com
To unsubscribe from this group, send email to
haml-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---


Re: HAML Performance
country flaguser name
United States
2007-11-06 11:02:24
Thank you for this information.  I had some naive ideas
about how you
were parsing and concatenating for HAML. It's good to see,
however,
how responsive you guys have been.  Obviously, there's been
a lot of
commitment to the project from the beginning, but it's
evidenced by
these kinds of discussions.

If I get any more ideas, I'll be sure to let you guys know.

David



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Haml" group.
To post to this group, send email to hamlgooglegroups.com
To unsubscribe from this group, send email to
haml-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---


[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )