JDK-8352891 Performance improvements to ByteArrayOutputStream
Archie Cobbs
archie.cobbs at gmail.com
Fri Mar 28 22:08:21 UTC 2025
This is just a drive-by, opinion-saturated comment, so feel free to
ignore...
I think the missing puzzle piece here is slightly different/more general
than "OutputStream into memory". IMHO what's really missing from the
standard toolbox provided by the JDK is the byte equivalent of
StringBuilder+String. In other words, just as String is a read-only wrapper
for a character array (or array range), and StringBuilder is used to build
a String, Java lacks a read-only container for byte array (or range), and
an associated builder. The "read-only" part is very important - as with
String, the internal byte[] array must be incorruptible and for the same
reasons.
If we had those two things, they would presumably be optimized for
performance already, so you would then have the building block needed to
create a more efficient version of ByteArrayOutputStream - by simply
wrapping an OutputStream around the builder (better yet, maybe the builder
already extends OutputStream).
I'm guessing adding such a thing has probably been discussed before and
rejected. If that's true, I'm not optimistic a less general solution to the
same overall problem would be accepted, but if there is interest on the
list for reconsidering such a thing I'd support it. Like many folks, I've
had to resort to writing my own implementation of just such a thing in the
past (and am happy to share it if interested).
-Archie
On Fri, Mar 28, 2025 at 7:06 AM Engebretson, John <jengebr at amazon.com>
wrote:
> Hi all! This message is to discuss the proposal for a public class that
> is faster/cheaper than ByteArrayOutputStream. Details are on the ticket
> [1] so I will only summarize here:
>
> - ByteArrayOutputStream is slower than the provided alternative, and
> wastes memory bandwidth and allocation.
>
> - The new alternative cannot replace ByteArrayOutputStream because BAOS
> exposes two implementation-specific fields.
>
> - The problem is broadly present, and different solutions exist in Spring,
> Tomcat, multiple applications inside my company, and undoubtedly elsewhere.
>
> - There are places within the JDK that will benefit from the improved
> performance.
>
>
>
> My goal is to broadly distribute this new datastructure, and the JDK is an
> obvious place to do it. My proposal is to publish a new public class,
> java.io.MemoryOutputStream extends OutputStream. I acknowledge the
> difficulties in doing so.
>
>
>
> I welcome any thoughts about the problem, solution, or deployment. I
> created a draft PR [2] for discussion or questions about the proposed
> implementation.
>
>
>
> 1. https://bugs.openjdk.org/browse/JDK-8352891
>
> 2. https://github.com/openjdk/jdk/pull/24232
>
--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250328/8afaaf3c/attachment.htm>
More information about the core-libs-dev
mailing list