The next step would be to take advantage of :ugly in Engine, to compile 
more efficient code in the first place. Then we won't need to muck 
around with conditionals at all, and most of the stuff in the buffer can 
be string concatenations.

- Nathan

Wincent Colaiuta wrote:
> El 14/2/2008, a las 5:30, Nathan Weizenbaum escribió:
>
>   
>> Okay, I've tweaked this a little and pushed it.
>>
>> The bad news is that the benchmarks don't register much change when
>> running in :ugly mode. Some of the runs seemed to be 5-10% faster, but
>> some seemed to be about the same amount slower, so it's hard to  
>> tell. I
>> was hoping for something more dramatic than this.
>>
>> However, the good news is that the benchmarks aren't perfect. I tested
>> the patch with exceptionally deep and reasonably large nested  
>> partials,
>> and the results were much more heartening. Before :ugly, the ratio
>> between Haml time and ERB time for both of these correlated with the
>> size/nestedness of partials. That is, 5-deep nesting might have Haml
>> rendering at 1.5x slower than ERB, while 30-deep nesting might have it
>> rendering 3x slower. However, with :ugly, Haml seems to be within 1.5x
>> of ERB no matter how deep the nesting gets.
>>
>> I'm not entirely sure what the cause of the 1.5x constant slowdown is.
>> It doesn't seem to show up for the flat benchmarks. I'm guessing it  
>> has
>> to do with the bookkeeping Haml::Buffer does, which can  
>> theoretically be
>> entirely eliminated when :ugly is set. So there's a clear path for
>> improvement.
>>     
>
> Well, currently the "rake profile" task shows that these are the  
> lowest-hanging fruit when :ugly is false:
>
>    %   cumulative   self              self     total
>   time   seconds   seconds    calls  ms/call  ms/call  name
>   14.07     0.64      0.64     1500     0.43     1.03   
> Haml::Buffer#push_script
>   11.21     1.15      0.51      136     3.75    37.21  Integer#times
>   10.33     1.62      0.47     1500     0.31     0.46   
> Haml::Buffer#push_text
>
> And these when :ugly is true:
>
>    %   cumulative   self              self     total
>   time   seconds   seconds    calls  ms/call  ms/call  name
>   18.69     0.80      0.80     1500     0.53     0.91   
> Haml::Buffer#push_script
>   13.79     1.39      0.59      136     4.34    35.96  Integer#times
>    8.64     1.76      0.37     1500     0.25     0.32   
> Haml::Buffer#push_text
>    5.84     2.01      0.25      915     0.27     0.32   
> Haml::Buffer#one_liner?
>
> But the numbers are all over the place: if you run the profile several  
> times you'll see them fluctuate wildly in both cases.
>
> In any case it's clear where the most time is being spent. I've only  
> included the first few lines above, but as you look at more lines the  
> pattern is relatively clear. With ":ugly" we're spending some extra  
> time evaluating conditionals, but we're also avoiding some work when  
> they evaluate to true. To make it run faster we'll have to find more  
> opportunities to reduce the work done, without adding too many more  
> conditionals (we don't want to slow down the ":ugly => false" case).  
> Of course, you already knew that!
>
> Cheers,
> Wincent
>
>
> >
>
>   


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to