On Sat, 13 Apr 2024 01:25:57 GMT, David Schlosnagle <d...@openjdk.org> wrote:
> Should the buffer size be a configurable constructor parameter? This would > allow consumers to adjust the buffer size to match their tradeoffs of memory > vs throughput based on workload & available resources, and provide a bit of > future-proofing as memory hierarchies expand over time (default 512 byte > buffer is a few decades old). I imagine many folks are already wrapping > `CipherInputStream` with a `BufferedInputStream` and this would allow folks > to adjust the buffer size in `CipherInputStream` and remove the extra wrapper > stream. > That would involve creating a new constructor and with that comes API change requirements. If InputStream hasn't supported this feature in the past, I don't think CipherInputStream needs it. > It would be nice to see a broader range of buffer sizes benchmarked across > architectures to understand the tradeoffs and differences in throughput. For > example, the default `InputStream` buffer size was increased from `8192` to > `16384` in JDK-8299336 / #11783 . > > There are also a number of architecture specific tradeoffs related to cipher > and intrinsics available that consumers may want to factor into buffer sizing. The larger the buffer the better in this case. AES/GCM can take advantage of the bigger buffer on AVX512 systems as it has a 786 byte requirement. I believe, all the others are blocksize. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18763#issuecomment-2065332979
