RFR 8193832: Performance of InputStream.readAllBytes() could be improved (original) (raw)
John Rose john.r.rose at oracle.com
Wed Dec 20 19:04:11 UTC 2017
- Previous message: RFR 8193832: Performance of InputStream.readAllBytes() could be improved
- Next message: RFR 8193832: Performance of InputStream.readAllBytes() could be improved
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Dec 20, 2017, at 3:45 AM, Peter Levart <peter.levart at gmail.com> wrote:
allocation of ArrayList could be avoided. Imagine a use case where lots of small files are read into byte[] arrays
+1 I was going to write a similar suggestion; thanks for sending it out.
These sorts of things often need to be designed to perform well at all scales, not just large scales.
The new ArrayList(8) is dead weight if the data fits in the buffer. So it's bad for scale < buffer length.
The earlier new ArrayList(128) is a noticeable overhead if the data fits in two buffers. So it's not so good for scale = M * (buffer length) where M is about 2.
For a large scale result (M > 10), the footprint difference between ArrayList(N) for various N is a second-order fraction.
— John
P.S. Road not taken: Instead of new ArrayList(8) you could use the default ArrayList constructor, and allocate it unconditionally. It has a very low overhead if the ArrayList remains empty. Using that constructor could motivate you to simplify the code to use the ArrayList unconditionally, since that would be just a single heap node if it is not used to gather multiple results. But I like the "null" formulation despite its complexity. So I'd probably keep it the way Peter wrote it.
- Previous message: RFR 8193832: Performance of InputStream.readAllBytes() could be improved
- Next message: RFR 8193832: Performance of InputStream.readAllBytes() could be improved
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]