JDK-8352891 Performance improvements to ByteArrayOutputStream

[Engebretson, John]

I’m prototyping the generic allocator you describe and it’s extremely effective for Objects – but I’m hamstrung by trying to use generics on primitive byte.  I’m not aware of a way to work around that, and changing the array from byte[] to Byte[] would be a terrible idea, so I think we’re looking at two different allocators.  The template suggested by Archie may help implement that, but ultimately it’ll be multiple classes.


My updated PR still pending (I want to do some cleanup) but I got some interesting results:

Replacing MOS with VariableLengthByteArray.asByteArrayOutputStream(): works great, perf is excellent.  A comment  on the PR suggested additional views such as InputStream and Channel, they will certainly work but will take a little time to implement.  I really like how much capability this brings.

The Object variant “VariableLengthObjectArray” came together very easily, however the performance characteristics of my first view (List<T>) gave me a few surprises.  Here’s the evaluation:

  1.  This grows more efficiently than either ArrayList or LinkedList.  Some variation across sizes.
  2.  This has higher capacity than ArrayList (no 2GB cap) or LinkedList (this is denser in heap)
  3.  This achieves log(n) on random inserts/removes, since it only modifies one segment.  That beats ArrayList (linear) or LinkedList (linear).
  4.  Random accesses such as get(5) are log(n), which is between ArrayList (constant) and LinkedList (linear).
  5.  Iterating is just a little slower than ArrayList thanks to overhead, but substantially faster than LinkedList
  6.  Head modifications such as LinkedList/Queue is log(n), which is better than ArrayList (linear) but worse than LinkedList (constant).

It seems like a good general-purpose list but I wouldn’t recommend it as a direct replacement for either ArrayList or LinkedList; in the former case the risk is slower random accesses, and in the latter the risk is to head modifications.

I can test new permutations of this fairly quickly, suggestions are welcome.

   John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250411/29c92af5/attachment-0001.htm>