=> 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 <stephane.ducasse@inria.fr> 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 <nicolas.cellier.aka.nice@gmail.com> 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