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