i10n or speed?

>
> On Mar 19, 2007, at 11:58 , Philippe Marschall wrote:
>
> > encodeForHTTP.
> >
> > So what do you find more important, that Seaside is fast or that is
> > supports non-ascii urls?
>
> I'm pretty sure you could have your cake and eat it, too, if you
> rewrite that method

> 2007/3/19, Bert Freudenberg <[hidden email]>:
>>
>> On Mar 19, 2007, at 11:58 , Philippe Marschall wrote:
>>
>> > encodeForHTTP.
>> >
>> > So what do you find more important, that Seaside is fast or that is
>> > supports non-ascii urls?
>>
>> I'm pretty sure you could have your cake and eat it, too, if you
>> rewrite that method
>
> We don't do overrides anymore.
>
>> using #indexOfAnyOf: and CharacterSets, which are
>> very fast.
>
> You would do this as a replacement for #isSafeForHTTP? Why not just a
> boolean Array and lookup by #charCode?

>
> On Mar 19, 2007, at 12:58 , Philippe Marschall wrote:
>
> > 2007/3/19, Bert Freudenberg <[hidden email]>:
> >>
> >> On Mar 19, 2007, at 11:58 , Philippe Marschall wrote:
> >>
> >> > encodeForHTTP.
> >> >
> >> > So what do you find more important, that Seaside is fast or that is
> >> > supports non-ascii urls?
> >>
> >> I'm pretty sure you could have your cake and eat it, too, if you
> >> rewrite that method
> >
> > We don't do overrides anymore.
> >
> >> using #indexOfAnyOf: and CharacterSets, which are
> >> very fast.
> >
> > You would do this as a replacement for #isSafeForHTTP? Why not just a
> > boolean Array and lookup by #charCode?
>
> Because it's much faster?

> 2007/3/19, Bert Freudenberg <[hidden email]>:
>>
>> On Mar 19, 2007, at 12:58 , Philippe Marschall wrote:
>>
>> > 2007/3/19, Bert Freudenberg <[hidden email]>:
>> >>
>> >> On Mar 19, 2007, at 11:58 , Philippe Marschall wrote:
>> >>
>> >> > encodeForHTTP.
>> >> >
>> >> > So what do you find more important, that Seaside is fast or  
>> that is
>> >> > supports non-ascii urls?
>> >>
>> >> I'm pretty sure you could have your cake and eat it, too, if you
>> >> rewrite that method
>> >
>> > We don't do overrides anymore.
>> >
>> >> using #indexOfAnyOf: and CharacterSets, which are
>> >> very fast.
>> >
>> > You would do this as a replacement for #isSafeForHTTP? Why not  
>> just a
>> > boolean Array and lookup by #charCode?
>>
>> Because it's much faster?
>
> A lookup in a boolean Array would be
> - a bit and for #charCode
> - an small integer comparison for <
> - #at: on an array
> how much faster can you get?

>> > Do you see any optimization potential in
>> > #encodeForHTTPWithTextEncoding:conditionBlock: ?
>>
>> If I'd see the code, probably.
>
> encodeForHTTPWithTextEncoding: encodingName conditionBlock:  
> conditionBlock
> "change dangerous characters to their %XX form, for use in HTTP  
> transactions"
>
> | httpSafeStream encodedStream cont |
> httpSafeStream _ WriteStream on: (String new).
> encodedStream _ MultiByteBinaryOrTextStream on: (String new: 6).
> encodedStream converter: (TextConverter newForEncoding:  
> encodingName).
> self do: [:c |
> (conditionBlock value: c)
> ifTrue: [httpSafeStream nextPut: (Character value: c charCode)]
> ifFalse: [
> encodedStream text; reset.
> encodedStream nextPut: c.
> encodedStream position: 0.
> encodedStream binary.
> cont _ encodedStream contents.
> cont do: [:byte |
> httpSafeStream nextPut: $%.
> httpSafeStream nextPut: (byte // 16) asHexDigit.
> httpSafeStream nextPut: (byte \\ 16) asHexDigit.
> ].
> ].
> ].
> ^ httpSafeStream contents.

>
> On Mar 19, 2007, at 13:34 , Philippe Marschall wrote:
>
> > 2007/3/19, Bert Freudenberg <[hidden email]>:
> >>
> >> On Mar 19, 2007, at 12:58 , Philippe Marschall wrote:
> >>
> >> > 2007/3/19, Bert Freudenberg <[hidden email]>:
> >> >>
> >> >> On Mar 19, 2007, at 11:58 , Philippe Marschall wrote:
> >> >>
> >> >> > encodeForHTTP.
> >> >> >
> >> >> > So what do you find more important, that Seaside is fast or  
> >> that is
> >> >> > supports non-ascii urls?
> >> >>
> >> >> I'm pretty sure you could have your cake and eat it, too, if you
> >> >> rewrite that method
> >> >
> >> > We don't do overrides anymore.
> >> >
> >> >> using #indexOfAnyOf: and CharacterSets, which are
> >> >> very fast.
> >> >
> >> > You would do this as a replacement for #isSafeForHTTP? Why not  
> >> just a
> >> > boolean Array and lookup by #charCode?
> >>
> >> Because it's much faster?
> >
> > A lookup in a boolean Array would be
> > - a bit and for #charCode
> > - an small integer comparison for <
> > - #at: on an array
> > how much faster can you get?
>
> A single primitive invocation for the whole string.
>
> >> > Do you see any optimization potential in
> >> > #encodeForHTTPWithTextEncoding:conditionBlock: ?
> >>
> >> If I'd see the code, probably.
> >
> > encodeForHTTPWithTextEncoding: encodingName conditionBlock:  
> > conditionBlock
> >       "change dangerous characters to their %XX form, for use in HTTP
> > transactions"
> >
> >       | httpSafeStream encodedStream cont |
> >       httpSafeStream _ WriteStream on: (String new).
> >       encodedStream _ MultiByteBinaryOrTextStream on: (String new: 6).
> >       encodedStream converter: (TextConverter newForEncoding:  
> > encodingName).
> >       self do: [:c |
> >               (conditionBlock value: c)
> >                       ifTrue: [httpSafeStream nextPut: (Character
> >                       value: c charCode)] ifFalse: [
> >                               encodedStream text; reset.
> >                               encodedStream nextPut: c.
> >                               encodedStream position: 0.
> >                               encodedStream binary.
> >                               cont _ encodedStream contents.
> >                               cont do: [:byte |
> >                                       httpSafeStream nextPut: $%.
> >                                       httpSafeStream nextPut: (byte //
> >                                       16) asHexDigit.
> >                                       httpSafeStream nextPut: (byte \\
> >                                       16) asHexDigit.
> >                               ].
> >                       ].
> >       ].
> >       ^ httpSafeStream contents.
>
> Yep. The whole thing could be avoided for ASCII strings with a single  
> #indexOfAnyOf: test. This would solve your original question, because  
> as long as you do not use non-ASCII characters it would be fast.
>
> - Bert -
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>
> On Mar 19, 2007, at 13:34 , Philippe Marschall wrote:
>
> > 2007/3/19, Bert Freudenberg <[hidden email]>:
> >>
> >> On Mar 19, 2007, at 12:58 , Philippe Marschall wrote:
> >>
> >> > 2007/3/19, Bert Freudenberg <[hidden email]>:
> >> >>
> >> >> On Mar 19, 2007, at 11:58 , Philippe Marschall wrote:
> >> >>
> >> >> > encodeForHTTP.
> >> >> >
> >> >> > So what do you find more important, that Seaside is fast or
> >> that is
> >> >> > supports non-ascii urls?
> >> >>
> >> >> I'm pretty sure you could have your cake and eat it, too, if you
> >> >> rewrite that method
> >> >
> >> > We don't do overrides anymore.
> >> >
> >> >> using #indexOfAnyOf: and CharacterSets, which are
> >> >> very fast.
> >> >
> >> > You would do this as a replacement for #isSafeForHTTP? Why not
> >> just a
> >> > boolean Array and lookup by #charCode?
> >>
> >> Because it's much faster?
> >
> > A lookup in a boolean Array would be
> > - a bit and for #charCode
> > - an small integer comparison for <
> > - #at: on an array
> > how much faster can you get?
>
> A single primitive invocation for the whole string.
>
> >> > Do you see any optimization potential in
> >> > #encodeForHTTPWithTextEncoding:conditionBlock: ?
> >>
> >> If I'd see the code, probably.
> >
> > encodeForHTTPWithTextEncoding: encodingName conditionBlock:
> > conditionBlock
> >       "change dangerous characters to their %XX form, for use in HTTP
> > transactions"
> >
> >       | httpSafeStream encodedStream cont |
> >       httpSafeStream _ WriteStream on: (String new).
> >       encodedStream _ MultiByteBinaryOrTextStream on: (String new: 6).
> >       encodedStream converter: (TextConverter newForEncoding:
> > encodingName).
> >       self do: [:c |
> >               (conditionBlock value: c)
> >                       ifTrue: [httpSafeStream nextPut: (Character value: c charCode)]
> >                       ifFalse: [
> >                               encodedStream text; reset.
> >                               encodedStream nextPut: c.
> >                               encodedStream position: 0.
> >                               encodedStream binary.
> >                               cont _ encodedStream contents.
> >                               cont do: [:byte |
> >                                       httpSafeStream nextPut: $%.
> >                                       httpSafeStream nextPut: (byte // 16) asHexDigit.
> >                                       httpSafeStream nextPut: (byte \\ 16) asHexDigit.
> >                               ].
> >                       ].
> >       ].
> >       ^ httpSafeStream contents.
>
> Yep. The whole thing could be avoided for ASCII strings with a single
> #indexOfAnyOf: test. This would solve your original question, because
> as long as you do not use non-ASCII characters it would be fast.

> 2007/3/19, Bert Freudenberg <[hidden email]>:
>>
>> On Mar 19, 2007, at 13:34 , Philippe Marschall wrote:
>>
>> > 2007/3/19, Bert Freudenberg <[hidden email]>:
>> >>
>> >> On Mar 19, 2007, at 12:58 , Philippe Marschall wrote:
>> >>
>> >> > 2007/3/19, Bert Freudenberg <[hidden email]>:
>> >> >>
>> >> >> On Mar 19, 2007, at 11:58 , Philippe Marschall wrote:
>> >> >>
>> >> >> > encodeForHTTP.
>> >> >> >
>> >> >> > So what do you find more important, that Seaside is fast or
>> >> that is
>> >> >> > supports non-ascii urls?
>> >> >>
>> >> >> I'm pretty sure you could have your cake and eat it, too, if  
>> you
>> >> >> rewrite that method
>> >> >
>> >> > We don't do overrides anymore.
>> >> >
>> >> >> using #indexOfAnyOf: and CharacterSets, which are
>> >> >> very fast.
>> >> >
>> >> > You would do this as a replacement for #isSafeForHTTP? Why not
>> >> just a
>> >> > boolean Array and lookup by #charCode?
>> >>
>> >> Because it's much faster?
>> >
>> > A lookup in a boolean Array would be
>> > - a bit and for #charCode
>> > - an small integer comparison for <
>> > - #at: on an array
>> > how much faster can you get?
>>
>> A single primitive invocation for the whole string.
>>
>> >> > Do you see any optimization potential in
>> >> > #encodeForHTTPWithTextEncoding:conditionBlock: ?
>> >>
>> >> If I'd see the code, probably.
>> >
>> > encodeForHTTPWithTextEncoding: encodingName conditionBlock:
>> > conditionBlock
>> >       "change dangerous characters to their %XX form, for use in  
>> HTTP
>> > transactions"
>> >
>> >       | httpSafeStream encodedStream cont |
>> >       httpSafeStream _ WriteStream on: (String new).
>> >       encodedStream _ MultiByteBinaryOrTextStream on: (String  
>> new: 6).
>> >       encodedStream converter: (TextConverter newForEncoding:
>> > encodingName).
>> >       self do: [:c |
>> >               (conditionBlock value: c)
>> >                       ifTrue: [httpSafeStream nextPut:  
>> (Character value: c charCode)]
>> >                       ifFalse: [
>> >                               encodedStream text; reset.
>> >                               encodedStream nextPut: c.
>> >                               encodedStream position: 0.
>> >                               encodedStream binary.
>> >                               cont _ encodedStream contents.
>> >                               cont do: [:byte |
>> >                                       httpSafeStream nextPut: $%.
>> >                                       httpSafeStream nextPut:  
>> (byte // 16) asHexDigit.
>> >                                       httpSafeStream nextPut:  
>> (byte \\ 16) asHexDigit.
>> >                               ].
>> >                       ].
>> >       ].
>> >       ^ httpSafeStream contents.
>>
>> Yep. The whole thing could be avoided for ASCII strings with a single
>> #indexOfAnyOf: test. This would solve your original question, because
>> as long as you do not use non-ASCII characters it would be fast.
>
> I owe you one, Pier just went from 8.74 request/sec to 19.24  
> request/sec.

> Hi
>
> Have you ever tried a counter in a recent version of Seaside? I don't
> know about you but for such a simple application it is way too slow
> for my taste. As part of the 2.8 cycle we look into ways of making
> Seaside faster.
>
> Attached you will find several traces for the counter application.
> As you can see, an awful lot of time is spent to convert URLs to
> String. Of that most time is spent in#encodeForHTTP.

> On Mon, 19 Mar 2007 11:58:11 +0100, Philippe Marschall wrote:
> > Hi
> >
> > Have you ever tried a counter in a recent version of Seaside? I don't
> > know about you but for such a simple application it is way too slow
> > for my taste. As part of the 2.8 cycle we look into ways of making
> > Seaside faster.
> >
> > Attached you will find several traces for the counter application.
> > As you can see, an awful lot of time is spent to convert URLs to
> > String. Of that most time is spent in#encodeForHTTP.
>
> I know how to speed up #isSafeForHTTP :)

> /Klaus
>
> > So what do you find more important, that Seaside is fast or that is
> > supports non-ascii urls?
> >
> > Cheers
> > Philippe
> >
> > P.S.: the original mail had several traces more but was apparently too
> > big, maybe it will arrive later.
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> 2007/3/19, Klaus D. Witzel <[hidden email]>:
>> On Mon, 19 Mar 2007 11:58:11 +0100, Philippe Marschall wrote:
>> > Hi
>> >
>> > Have you ever tried a counter in a recent version of Seaside? I don't
>> > know about you but for such a simple application it is way too slow
>> > for my taste. As part of the 2.8 cycle we look into ways of making
>> > Seaside faster.
>> >
>> > Attached you will find several traces for the counter application.
>> > As you can see, an awful lot of time is spent to convert URLs to
>> > String. Of that most time is spent in#encodeForHTTP.
>>
>> I know how to speed up #isSafeForHTTP :)
>
> 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.

>> what details are touched by
>> #encodeForHTTP and #isSafeForHTTP.
>
> URL generation for anchors and stuff.
>
> Philippe.
>
>> /Klaus
>>
>> > So what do you find more important, that Seaside is fast or that is
>> > supports non-ascii urls?
>> >
>> > Cheers
>> > Philippe
>> >
>> > P.S.: the original mail had several traces more but was apparently too
>> > big, maybe it will arrive later.
>>
>>
>> _______________________________________________
>> Seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>

> On Mon, 19 Mar 2007 17:17:56 +0100, Philippe Marschall wrote:
> > 2007/3/19, Klaus D. Witzel <[hidden email]>:
> >> On Mon, 19 Mar 2007 11:58:11 +0100, Philippe Marschall wrote:
> >> > Hi
> >> >
> >> > Have you ever tried a counter in a recent version of Seaside? I don't
> >> > know about you but for such a simple application it is way too slow
> >> > for my taste. As part of the 2.8 cycle we look into ways of making
> >> > Seaside faster.
> >> >
> >> > Attached you will find several traces for the counter application.
> >> > As you can see, an awful lot of time is spent to convert URLs to
> >> > String. Of that most time is spent in#encodeForHTTP.
> >>
> >> I know how to speed up #isSafeForHTTP :)
> >
> > 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]]) ?

> Cheers
> Klaus
>
> >> what details are touched by
> >> #encodeForHTTP and #isSafeForHTTP.
> >
> > URL generation for anchors and stuff.
> >
> > Philippe.
> >
> >> /Klaus
> >>
> >> > So what do you find more important, that Seaside is fast or that is
> >> > supports non-ascii urls?
> >> >
> >> > Cheers
> >> > Philippe
> >> >
> >> > P.S.: the original mail had several traces more but was apparently too
> >> > big, maybe it will arrive later.
> >>
> >>
> >> _______________________________________________
> >> Seaside mailing list
> >> [hidden email]
> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> >>
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

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

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

> On Mon, 19 Mar 2007 18:17:31 +0100, Philippe Marschall wrote:
> > 2007/3/19, Klaus D. Witzel <[hidden email]>:
> >> 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
> >
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Philippe Marschall
> Enviado el: Lunes, 19 de Marzo de 2007 07:47
> Para: Seaside - general discussion
> Asunto: [Seaside] i10n or speed?
>
> Hi
>
> Have you ever tried a counter in a recent version of Seaside?
> I don't know about you but for such a simple application it
> is way too slow for my taste. As part of the 2.8 cycle we
> look into ways of making Seaside faster.
>
> Attached you will find several traces for the counter application.
> As you can see, an awful lot of time is spent to convert URLs
> to String. Of that most time is spent in#encodeForHTTP.
>
> So what do you find more important, that Seaside is fast or
> that is supports non-ascii urls?
>
> Cheers
> Philippe
>