JDK-8352891 Performance improvements to ByteArrayOutputStream

[Archie Cobbs]

To try to loop back on my original point...

The "underlying problem" that I think should be addressed by some new
internal class (or suite of classes) is the "array builder" problem. This
is where you're doing "append, append, append, ..., use read-only
thereafter".

Currently people use ArrayList for that, or for primitive arrays, homebrew
it with System.arraycopy() - or maybe I'm missing something like this that
already exists?

I would like to see JDK standard "array builders" for primitive types and
reference types that use fixed sized (power-of-two) segments internally.
These can be internal classes for now.

Then the faster ByteArrayOutputStream becomes just a wrapper around
"ByteArrayBuilder" or whatever we call it.

This is all just my opinion, I'm curious if others perceive the same gap
that I do?

-Archie


On Fri, Apr 11, 2025 at 10:15 AM Archie Cobbs <archie.cobbs at gmail.com>
wrote:

> On Fri, Apr 11, 2025 at 8:11 AM Engebretson, John <jengebr at amazon.com>
> wrote:
>
>> 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.
>>
>
> Interesting results. However I don't think comparing this to both
> ArrayList and LinkedList is really fair. Developers choose an
> implementation based on how they know they are going to use it: If they are
> just adding stuff, they choose ArrayList. If they know they need to
> insert/remove in the middle, they choose LinkedList. If they need to
> add/remove from both ends, they choose ArrayDeque. Etc.
>
> So the optimal design changes depending on which "flavor" of list usage
> the developer is implying when they choose some implementation class.
>
> E.g., if you wanted to target the "ArrayList flavor', then you'd use fixed
> size, power-of-two segments. Then get() remains constant time, and insert
> and remove remain as painfully slow as ever, but the common "list builder"
> usage pattern of "append, append, append, ..., use read-only thereafter"
> gets a lot faster.
>
> OTOH variable-sized chunks makes lots of sense for the "LinkedList"
> flavor. In fact you could have a LinkedList<T> that just uses an
> ArrayList<ArrayDeque<T>> internally :)
>
> -Archie
>
> --
> Archie L. Cobbs
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250411/391719ee/attachment-0001.htm>