On Mon, 30 Aug 2010, Henrik Johansen wrote:
On Aug 30, 2010, at 2:57 47PM, Levente Uzonyi wrote:
On Mon, 30 Aug 2010, Henrik Johansen wrote:
On Aug 30, 2010, at 1:06 10PM, Levente Uzonyi wrote:
On Mon, 30 Aug 2010, Stéphane Ducasse wrote:
I suggest that the people that want and know, group together and build an open-source one.
Why do you have to have your "own" library?
Did I say "pharo library"? reread carefully I said an "open-source one".
What I get from Andreas' words is that he's willing to make it open source if it won't be forked.
So, definitely not MIT then.
Why? Because the MIT license explicitly sets no limit on the users right to modify, publish and distribute the software. A condition that it can not be published/used in a modified (forked) form would exclude using MIT.
Andreas may still decide to release the source under the MIT license.
I guess that means the long-term plan of replacing HttpSocket in Squeak is out as well?
I don't think so. Squeak releases won't come with WebClient loaded, Andreas mentioned it in his mail.
In a reply to the original announcement, Andreas also said:
"On 5/4/2010 11:11 PM, Casey Ransberger wrote:
Are you intent on replacing HTTPSocket in the long run? I have an RPC-ish thing that uses it, so I'd like to be clear on whether I can expect it to be around for the next release.
In the long run: Yes. In the next release: No. And "replacing" can mean that the public interface in HTTPSocket remains. That's what the WebClient-HTTP package does. It patches HTTPSocket to use WebClient while preserving the identical external interface. "
which to me implied eventual integration in Squeak core (as did the removal of HttpSocket functionality based on it being offered by WebClient)
So you can expect the code to be released under MIT, but maybe not now. :)
If you call (re)introducing #squeakToUtf8/#utf8ToSqueak instead of using convertTo/FromEncoding: 'utf8', then yes.
In Squeak these methods avoid the creation of the TextConverter object if the receiver is a ByteString, which is usually the case.
Levente
Yes, the major performance differences come from not creating copies if the strings are ascii, and #convertTo/FromEncoding: doing subclass lookup to find the converter though.
I mean, no converter objects are created.
AFAICT, it's maximally about 2 times faster in the best case (small, pure ascii strings) where it avoids both copies and a lookup compared to a convertTo/FromEncoding modified to do lookup in a dictionary rather than iterating subclasses.
For the WebSocket use-cases though, I really don't see how the performance matters all that much.
More objects -> more gc. It probably doesn't matter if the image doesn't have to handle heavy load.
You convert roughly 200k 4KB ascii strings per second either way, and with a single non-ascii char, the difference falls to near negligible.
"MediumDoc is a pure ascii ByteString of size 4096" [1 to: 100000 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 362 384 [1 to: 100000 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 437 564
In Squeak(CogVM): "7-bit ByteString" mediumDoc := ByteString new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 100000 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. "===> #(344 345 344 347 344)" (1 to: 5) collect: [ :run | [ 1 to: 100000 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. "===> #(404 373 375 374 374)" (1 to: 5) collect: [ :run | [ 1 to: 100000 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. "===> #(1443 1440 1438 1443 1445)" "7-bit ByteString with a single 8-bit character" mediumDoc := ByteString new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. mediumDoc at: 2048 put: (Character value: 128). (1 to: 5) collect: [ :run | [ 1 to: 100000 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. "===> #(1262 1246 1249 1250 1249)." (1 to: 5) collect: [ :run | [ 1 to: 100000 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. "===> #(1261 1256 1264 1260 1258)" (1 to: 5) collect: [ :run | [ 1 to: 100000 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. "===> #(2591 2567 2538 2543 2582) Not neglible (~0.5 speed)" "8-bit ByteStrings (only 1000 conversion/test)" mediumDoc := ByteString new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: 256 atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. "===> #(627 618 618 622 618)" (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. "===> #(648 621 620 621 622)" (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. "===> #(676 653 650 658 648)" "WideStrings" mediumDoc := String new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: (1<<22) atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. "===> #(632 635 633 632 633)" (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. "===> #(693 625 625 626 625)" (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. "===> #(644 637 640 640 638)" So, for 7-bit ByteStrings (optionally with few 8-bit characters), it does make a difference to use #squeakToUtf8, for 8-bit ByteStrings and WideStrings it doesn't really matter. Levente
MediumDoc at: 2048 put: $?. [1 to: 100000 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 1451 1438 [1 to: 100000 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 1463 1470
Cheers, Henry