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
