improving rendering performance (on Pharo)

Hi

While hacking on an encoding prototype I found a way to improve
Seaside rendering performance on Pharo. We spend quite a lot of time
in WAEncoder >> #nextPutAll:. I realized I could use the same trick we
use in for UTF-8 encoding. Most of the content we don't have to escape
so if we can quickly decide that we don't need to escape the contents
we can just do a #nextPutAll:. Pharo has a primitive for exactly this.

So how much is it worth? The somewhat synthetic Seaside Performance
Index goes through the roof (before [1] after [2]) and
WALotsLinksFunctionalTest goes from about 900ms to about 500 ms.

The code is in Grease-Core-pmm.38, Grease-Pharo-Core-pmm.20,
Seaside-Core-pmm.636. Right now the code is hacked in and has a slow
default fallback on GRPlatform. I believe I could make it a bit faster
for cases where only very little content needs to be escaped (think a
huge text block with a single & in the middle). The question is where
we go from here, in the end we pretty much have methods for escaping
XML and URL in platform with the current implementation on GRPlatform
as fallback.

 [1] http://imgur.com/FftPH.png
 [2] http://imgur.com/qlivp.png

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2010/5/21 Julian Fitzell <[hidden email]>:

> So when you say hacked in, you mean I should try not to include these
> versions this weekend? :)

No, by all means include it so that it gets tested. What I mean is the
code is probably not going to stay in the state it is currently in.
Which doesn't matter so much for Pharo but matters for everybody else
who wants to build an optimized implementation for his platform.

> I'm afraid your question doesn't leave me with enough information to provide
> an opinion. Obviously faster == better, but what's the downside? I don't
> quite understand what the end result is.

The end result is methods on platform for escaping xml and urls with
the current code the default implementation on GRPlatform.

On Fri, May 21, 2010 at 13:35, Philippe Marschall

<[hidden email]> wrote:
> 2010/5/21 Julian Fitzell <[hidden email]>:
>> On Fri, May 21, 2010 at 8:46 AM, Philippe Marschall
>> <[hidden email]> wrote:
>>>
>>> 2010/5/21 Julian Fitzell <[hidden email]>:
>>> > So when you say hacked in, you mean I should try not to include these
>>> > versions this weekend? :)
>>>
>>> No, by all means include it so that it gets tested. What I mean is the
>>> code is probably not going to stay in the state it is currently in.
>>> Which doesn't matter so much for Pharo but matters for everybody else
>>> who wants to build an optimized implementation for his platform.
>>>

>>> The end result is methods on platform for escaping xml and urls with
>>> the current code the default implementation on GRPlatform.

I think "^true" will be faster for the default platform, especially for
#includesUnsafeUrlCharacter:  If you interpret that as the method
having false positives, but not false negatives, you can even
keep some testcases.

With this change I have no reason to complain about this optimization.

Paolo

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev