After more experiments I'm less enthusiastic about providing an optimized BufferedReader. The result of the performance test is significantly different if the test is run alone or after all the other unit tests (about 30% slower). When all the tests are executed, the removal of the synchronized blocks in BufferedReader has no visible effect (maybe less than 1%), and the Harmony implementation becomes slower.

Emmanuel Bourg


Le 13/03/2012 10:20, Emmanuel Bourg a écrit :
Le 13/03/2012 02:47, Niall Pemberton a écrit :

IMO performance should be taken out of the equation by using the
Readable interface[1]. That way the users can use whatever
implementation suits them (for example using an underlying buffered
InputStream) to change/improve performance.

I you mean that the performance of BufferedReader should be taken out of
the equation then I agree. All CSV parsers should be compared with the
same input source, otherwise the comparison isn't fair.

Using Readable would be really nice, but that's very low level. We would
have to build line reading and mark/reset on top of that, that's almost
equivalent to reimplementing BufferedReader.

If [io] could provide a BufferedReader implementation that:
- takes a Readable in the constructor
- does not synchronize reads
- recognizes unicode line separators (and the classic ones)

then I buy it right away!

Emmanuel Bourg



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to