[Seaside] Re: i10n or speed?

[Klaus D. Witzel]

On Mon, 19 Mar 2007 18:17:31 +0100, Philippe Marschall wrote:
> 2007/3/19, Klaus D. Witzel <klaus.witzel at cobss.com>:
>> On Mon, 19 Mar 2007 17:17:56 +0100, Philippe Marschall wrote:
...
>> > At the string level I now use #isByteString + #indexOfAnyOf: with a
>> > character set of unsafe latin1 characters.
>> > At the character level I use
>> >
>> > (aCharacter charCode < 128 and: [ (unsafeCharacterSet includes:  each)
>> > not ])
>> >
>> > works pretty dandy so far.
>>
>> Sure. Must be so, for #isByteString cases :)
>>
>> >> Could you make me the traces
>> >> again, with the following "correction": there seems to be an #ensure:
>> >> (at
>> >> the top of tree) which seems to obscure,
>> >
>> > That's from the MessageTally.
>>
>> Never seen that; do you see it in (MessageTally spyOn: [12345  
>> timesRepeat:
>> [Processor nextReadyProcess]]) ?
>
> No, I think it comes from the way SeasidePlatformSupport uses
> MessageTally. If I directly use MessageTally spyOn: I get debuggers in
> the world update loop and red morphs with yellow crosses.

I'm afraid I always try to avoid such dangerous things (red morphs with  
yellow crosses :) Anyways, thanks now I can see where #ensure: in your  
traces comes from.

>> > What excatly do you want to have profiled?
>>
>> The levels underneath #encodeForHTTP and #isSafeForHTTP, for all the  
>> cases
>> for which #isByteString returnes false. Exactly enough?
>
> Well I just got rid of them all. If it isn't an ASCII character then
> it is not safe for HTTP. No need to go into EncodedCharSets and
> friends. If it is an ASCII character, well, there is the CharacterSet
> of unsafe latin1 characters that does a pretty fast lookup.

You must be happy then, as long as Seaside just creates responses and  
sends them to some browser ;-)

How about the request side, header parsing, request body parsing? No i18n  
anywhere in request data processing, no #isLetter, no #isDigit ?

/Klaus

> Philippe
>