pjfanning commented on PR #3737: URL: https://github.com/apache/pekko/pull/3737#issuecomment-6520101616
Quick JMH run of `TlsBenchmark.warmRoundTrip` (`implementation=graphstage`): 1000 records through an in-memory client/server TLS pair. The server's ciphertext input crosses an async boundary from the client stage, so this exercises the changed path. `sbt "bench-jmh/Jmh/run -wi 3 -i 5 -f1 -t1 -p implementation=graphstage .*TlsBenchmark.warmRoundTrip"`, JDK 17, macOS laptop. Baseline = this branch with `cipherIn` added back to `UnbatchedInput` (i.e. the behaviour on `main`). | payload | this PR (ops/ms) | baseline (ops/ms) | |---|---|---| | 256 B | 94.7 ± 53.8 | 111.2 ± 62.7 | | 4 KiB | 21.5 ± 19.7 | 33.6 ± 31.4 | | 64 KiB | 4.90 ± 2.23 | 4.97 ± 2.43 | This does **not** show an improvement. The error bars overlap everywhere, but the baseline is nominally faster at 256 B and 4 KiB (4 KiB iterations: 15–27 ops/ms here vs 24–46 baseline), and 64 KiB is flat. One fork, short iterations and a laptop make this noisy, and the two variants ran sequentially rather than interleaved, so it isn't conclusive either way. This benchmark is also round-trip/echo shaped, where batches are often a single element; it doesn't model bulk inbound transfer. I'd treat the perf benefit of this PR as unproven until a longer run (more forks, interleaved variants) or a bulk-inbound benchmark shows it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
