On Tue, Mar 20, 2018 at 8:57 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
> On 20 Mar 2018, at 00:19, Sean P. DeNigris <sean@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 Phone: +33 06 52 70 66 13 |
