RFR: 8344144: AES/CBC slow at big payloads [v2]

[Ferenc Rakoczi]

On Thu, 14 Nov 2024 20:59:36 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Given this is a performance change, I'm fine with leaving it as is.  Jumping to a helper method with an encrypt/decrypt conditional check for every crypto op will costs performance.  This is a case where more efficient code is more verbose syntax.
>
> @ascarpino But a method call should be very cheap, we are adding a bunch of extra implEncrypt/implDecrypt calls here already. Besides, compiler/hotspot will optimize that call if needed. It will be just a method wrapping the `for` loop.

I don't think it matters either way performance-wise, or from any other point of view in this case, but as a rule of thumb, I think for readability/maintainability it is worth to give up a bit of code size (especially if that is only source code size, since the compiler would duplicate the runtime code anyways) and/or performance. Of course, it is hard to decide which version is more readable/maintainable. For me, in this case, the source code duplication seems to be the better solution, I would not write a helper function for a 3-line for loop. I have spent many hours of my life trying to figure out whether I brake something if I make a little change in a function that appears on multiple code paths...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22086#discussion_r1843378422