We can cover this case by extra variable maxBufferSize. By default it would be equal to given size in method #sizeBuffer:. And special users will specify concrete value. FileHandler will use file size for this. It will also improve buffer size for small files where we do not need big buffer.
2018-03-20 9:57 GMT+01:00 Guillermo Polito <guillermopol...@gmail.com>: > > > On Tue, Mar 20, 2018 at 8:57 AM, Sven Van Caekenberghe <s...@stfx.eu> > wrote: > >> >> >> > On 20 Mar 2018, at 00:19, Sean P. DeNigris <s...@clipperadams.com> >> wrote: >> > >> > Guillermo Polito wrote >> >> I've done also some profiling and it does not look like we've lost in >> >> performance either (reading and decoding a 35MB file): >> > >> > Your 1st (new API) example: "0:00:00:01.535" >> > Your 2nd (old API) example:"0:00:00:01.732" >> > *** but *** >> > Your 1st (new API) example using the same consuming selector as example >> #1 >> > (#upToEnd): "0:00:00:07.816" or 4.5x slower >> >> Yes and no ;-) >> >> Look at MultiByteFileStream>>#upToEnd where they cheat a bit and do >> basically the same as example 1 using #next: >> >> The Zn #upToEnd implementation does not use size knowledge (as streams >> are infinite). >> >> As a side note: using #size and #position[:] on variable encoded streams >> like UTF8 is *very* dangerous and should be avoided. Counting/indexing >> bytes in the underlying stream is *not* the same as counting/indexing >> decoded characters. It can be the source of subtle bugs. >> > > Sean, > > Think that the Buffered stream can be reused in the context of sockets > too. And there size has no meaning. > > Basically the cost in there is on growing and copying the internal buffer > used to read. This buffer for the 35M file ends up being ~35M, so it has to > grow and copy several times... > Using #next: will preallocate the good size for the internal buffer. > > Now, I'd say first that if people want performance they should use the > good API :). > > Maybe the ZnBuffered stream could ask its underlying stream for its # > preferredInternalBufferSizeForUpToAll. But that would contaminate all the > stream hierarchy... Is it worth it? Dunno... > > >> >> >> > ----- >> > Cheers, >> > Sean >> > -- >> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >
