2018-03-20 10:15 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>:
> We can cover this case by extra variable maxBufferSize.
>
Operations like upToEnd will relocate maximum buffer.
#next: related methods can be also improved by it too. We will need extra
method:
ZnBufferedReadStream>>nextBuffer: requiredSize
newBufferSize := requiredSize min: maxBufferSize max: minBufferSize.
buffer size = newBufferSize ifFalse: [
buffer := self collectionSpecies new: size].
limit := stream readInto: buffer startingAt: 1 count: buffer size.
position := 1
But it will require another variable minBufferSize.
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>
>>
>
>
