On Mon, 15 Apr 2024 19:34:18 GMT, Anthony Scarpino <ascarp...@openjdk.org> wrote:
>> Can you provide memory usage difference between the current and your >> suggested change with `-prof gc`? With many of these situations, it's a >> balance between memory usage and performance. > >> @ascarpino here's the `-prof gc` results. Allocations per operation are very >> similar except for encryption for the smaller data size which is >> significantly increased with the higher buffer size. I think it's a good >> tradeoff. >> > > Benchmark (dataSize) Score Error Units > == buffer size = 512 (current) == > encrypt:gc.alloc.rate 16384 1991.982 +- 162.581 MB/sec > encrypt:gc.alloc.rate 1048576 1062.342 +- 4.239 MB/sec > == buffer size = 8192 (this PR) == > encrypt:gc.alloc.rate 16384 4066.224 +- 338.790 MB/sec > encrypt:gc.alloc.rate 1048576 1615.335 +- 36.420 MB/sec > > > @olivergillespie Thanks for the data. Any theories why encryption memory > usage jumped up when the decryption are very close? @ascarpino We should look at the normalized (per op) allocation data, not the total values, because otherwise higher throughput makes the allocation rate look worse, when really it's just doing more operations per time. Looking at the normalized encrypt results, both the small and large payload size add around 23KB per op. Benchmark (dataSize) Score Error Units == buffer size = 512 (current) == encrypt:gc.alloc.rate.norm 16384 35584.003 +- 0.001 B/op encrypt:gc.alloc.rate.norm 1048576 1067786.612 +- 329.146 B/op == buffer size = 8192 (this PR) == encrypt:gc.alloc.rate.norm 16384 58624.003 +- 0.001 B/op encrypt:gc.alloc.rate.norm 1048576 1090816.131 +- 0.003 B/op Profiling data shows that this comes from: 1. Allocating `ibuffer` in `CipherInputStream.<init>` 2. Expanding `obuffer` in `CipherInputStream.ensureCapacity` 3. Allocating buffer in `GaloisCounterMode$GCMEncrypt.doUpdate` Each is a single allocation of the increased buffer size, so an increase of 8192-512 bytes, x3, which accounts perfectly for the +23KB observed. These are done once, so they have less relative impact on larger data sizes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18763#issuecomment-2058833945
