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.about.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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > So, I quickly grabbed a copy of the "rope" > > library.https://rubyforge.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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [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 -~----------~----~----~----~------~----~------~--~---
