Measuring throughput with JMH parameters `-f 1 -i 2 -wi 3 -r 20 -w 30 -p algorithm=AES/CBC/NoPadding -p dataSize=30000000 -p provider=SunJCE -p keyLength=128 org.openjdk.bench.javax.crypto.full.AESBench`
Before: Benchmark (algorithm) (dataSize) (keyLength) (provider) Mode Cnt Score Error Units AESBench.decrypt AES/CBC/NoPadding 30000000 128 SunJCE thrpt 2 25.383 ops/s AESBench.decrypt2 AES/CBC/NoPadding 30000000 128 SunJCE thrpt 2 32.230 ops/s AESBench.encrypt AES/CBC/NoPadding 30000000 128 SunJCE thrpt 2 20.489 ops/s AESBench.encrypt2 AES/CBC/NoPadding 30000000 128 SunJCE thrpt 2 21.383 ops/s After: Benchmark (algorithm) (dataSize) (keyLength) (provider) Mode Cnt Score Error Units AESBench.decrypt AES/CBC/NoPadding 30000000 128 SunJCE thrpt 2 215.144 ops/s AESBench.decrypt2 AES/CBC/NoPadding 30000000 128 SunJCE thrpt 2 411.265 ops/s AESBench.encrypt AES/CBC/NoPadding 30000000 128 SunJCE thrpt 2 64.341 ops/s AESBench.encrypt2 AES/CBC/NoPadding 30000000 128 SunJCE thrpt 2 73.114 ops/s I have not deterministically proven why chunking works: before the change, the CBC intrinsic is not being used; and after chunking, it is. There is quite a bit of GC activity in the default AESBench, so `encrypt2/decrypt2` versions isolate just crypto (see comment below). ------------- Commit messages: - chunk cbc intrinsic Changes: https://git.openjdk.org/jdk/pull/22086/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22086&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344144 Stats: 27 lines in 1 file changed: 24 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22086/head:pull/22086 PR: https://git.openjdk.org/jdk/pull/22086
