> 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. > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >
