Revisit Varint performance with Java 25

[jasperpotts]

Make sure we are using the first code for varint encoding and decoding in all places. Fastest on Java 25 on Intel and AMD.

We have had many implementations over time. Should check them all and benchmark them on Java 25

Previous work for reference
See #596

[anthony-swirldslabs]

I found the PR where the varing reading implementation was changed, and a specific comment where @artemananiev and I discussed this: #144 (comment)

The linked benchmark results are here: #67 (comment) (also see a comment right above with "before the fix" results.)

Apparently, the old implementation had a bug (#143), so we had to change it anyway. And per the benchmark results, it seems to be 2x faster or thereabout.

Since we cannot use the original code because of the bug, we'd have to re-implement a new version if we want to test other options. However, from the varint format itself, it appears that we have to perform a single conditional branch after reading each and every byte of the varint encoding. The condition is trivial, and so is the math for incorporating a new byte. The number of conditional branch instructions is always equal to the number of bytes in the encoding, and hence there's no way to optimize the number of conditionals. E.g. consider:

"optimized":

b = readByte();
if (b > 0) {
   return b;
} else { // fast-paths for 2 and maybe 3 bytes, and then just loop
   // read more bytes and incorporate them into the already read `b` value above
}

current - just loop for each byte:

       long value = 0;

        for (int i = 0; i < 10; i++) {
            final byte b = readByte();
            value |= (long) (b & 0x7F) << (i * 7);
            if (b >= 0) {
                return zigZag ? (value >>> 1) ^ -(value & 1) : value;
            }
        }
        throw new DataEncodingException("Malformed var int");

I see that the current implementation performs two conditional checks - one in for and another in the inner if. So from this perspective, it seems less optimal than the optimized one. However, it's trivial to fix that by converting the for loop into a do/while loop so that the first conditional is skipped in case of 1 byte varint.

Other than that, it's difficult to see what else can be optimized in this algorithm from practical perspective.

[anthony-swirldslabs]

With #797 , a benchmark for reading varints was introduced. Per results obtained on an aarch64 Mac, it seems that we may benefit from unrolling the loop in the varint implementation.

I've asked @alex-kuzmin-hg to run the bench on Intel (and AMD if available) Linux systems to see the results on production architectures. If they align with what I got, then we'll go ahead and unroll the loops.

(see sub-issues at the top of this issue for all the work going on.)