=> Xtreams and Pharo 3.0 ;) I think anything else is a major waste of time :P
On 2012-12-05, at 14:53, Stéphane Ducasse <[email protected]> wrote: > one day we will have to address the old streams :) > > > On Dec 3, 2012, at 9:44 PM, Sven Van Caekenberghe wrote: > >> >> On 03 Dec 2012, at 19:24, Nicolas Cellier >> <[email protected]> wrote: >> >>> Yes, the lack of FileStream buffering was (re)-discovered and >>> corrected when I have experimented with my own SqueaXTream experiments >>> http://www.squeaksource.com/XTream/ before porting the original >>> Xtreams to Squeak http://www.squeaksource.com/Xtreams/ >>> Then Levente soon came up with an excellent patch for buffering Squeak >>> FIleStream and this was later ported to Pharo. >>> >>> What I also re-discovered is that not only buffering the raw file >>> counts, but also buffering the decoding. >>> Indded, an uncarefull implementation would read file by chunk but >>> decode byte after byte... >>> While a buffered one would decode large chunks of ASCII (if any) in a >>> single copy primitive. >>> >>> This was reported near the end of this post: >>> http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.general/151341 >>> >>> For Xtreams, I don't remember exactly where I put some experiments, >>> but pre-allocating a WideString instead of a String can also make a >>> noticeable difference in presence of WideCharacter... >> >> Many people seem to be rediscovering the same problems, not a good sign ;-) >> >> I think that in particular MultiByteFileStream>>#peek is not efficient. >> >> Yeah, there seems to be a WideString construction issue as well, I haven't >> looked into it yet. >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >> >> > >
