We can already have relatively fast UTF8 reading when the file is essentially composed of ascii. I've demonstrated this a few years ago with SqueaXtreams ( http://www.squeaksource.com/XTream/) For example, see http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141577.... I don't want to sell SqueaXtreams, it was just an experiment, but the good ideas should be extracted, we don't have to wait for a new VM. Nicolas Cellier (eh, I now have to disambiguate, maybe i will sign NiCe...) 2015-03-17 19:58 GMT+01:00 phil@highoctane.be <phil@highoctane.be>:
Le 17 mars 2015 18:59, "Stephan Eggermont" <stephan@stack.nl> a écrit :
On 17/03/15 17:59, Stephan Eggermont wrote:
I tried the code with the latest pharo-spur image and vm: from 17 seconds down to 10.5
And I tried it again with cogspurlinux 3268 and the trunk46-spur. That needed switching to
MultiByteFileStream readOnlyFileNamed:
and ran in 8.8 sec (average of three runs). Interestingly, on Pharo that is significantly slower, about 15 sec.
replacing that by StandardFileStream (and no decoding) reduced it to <120 ms.
Maybe using FFI to read the file in the correct format would be a nice option to have available.
The code in the MultibyteFileStream looks quite convoluted when reading.
There is reason we need a 64 it VM to read a UTF8 file fast. (8secs really does not qualify)
Opinions?
Phil
Stephan
[1 to: 10 do: [:j | |a length| length := 0. a := (MultiByteFileStream readOnlyFileNamed:
'/home/stephan/Downloads/jfreechart.mse') readStream contents]] timeToRunWithoutGC