[Seaside] Re: i10n or speed?
Klaus D. Witzel
klaus.witzel at cobss.com
Mon Mar 19 18:06:40 UTC 2007
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
>> [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
>> 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 ?
More information about the seaside