[Seaside] Re: i10n or speed?

Philippe Marschall philippe.marschall at gmail.com
Mon Mar 19 18:17:04 UTC 2007


2007/3/19, Klaus D. Witzel <klaus.witzel at cobss.com>:
> 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 ?

only #unescapePercents which hasn't turned out to be a bottleneck so far.

Philippe

> /Klaus
>
> > Philippe
> >
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>


More information about the seaside mailing list