On Fri, 15 Nov 2024 12:52:28 GMT, Artur Barashev <abaras...@openjdk.org> wrote:
>> 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... > > I see, I agree it will add to the learning curve for somebody new looking at > the code. Keeping things the way they are has its merits. It won't be 3 lines > though, we would replace all those 9 lines with 1 line: > `return chunkOperation(cipher, cipherOffset, cipherLen, plain, plainOffset, > false);` I would prefer to leave it as is; two reasons.. I do think its more readable 'not to have to track down the one-liner function'. I admit this is a matter of taste, so 'can be convinced otherwise'. But the second reason, I don't know that we should rely on the JIT necessarily inlining things.. (Anecdotally.. I 'cleaned up' `(Montgomery)IntegerPolynomialP256.mult` with a `for(i = 0:4)` loop that can clearly be unrolled but makes for much more readable code. Never was unrolled) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22086#discussion_r1844308172
