Speed up writeVInt

[nik9000]

This speeds up StreamOutput#writeVInt quite a bit which is nice
because it is very commonly called when serializing aggregations. Well,
when serializing anything. All "collections" serialize their size as a
vint. Anyway, I was examining the serialization speeds of StringTerms
and this saves about 30% of the write time for that. I expect it'll be
useful other places.

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/Core)

[nik9000]

This was just wrong.

[nik9000]

I'm unsure if we actually want this benchmark, especially compared to the one that @jimczi showed me. But it is fairly targeted which can be useful.

[nik9000]

this saves about 30% of the write time for that

The attached benchmark goes from 90ms to serialize the agg to 60ms to serialize the agg. This has a million buckets which is quite a bit, but nothing we don't bump into from time to time.

[nik9000]

This gets compiled to lzcnt and the JVM's tableswitch. At this point the overhead of the buffer and BigArrays dominates the method.

[original-brownbear]

Nice find! Let me know what you think about my inline point.

[original-brownbear]

I love this until here :) The fact that we can special case number of leading zeros > 24 is pretty significant and I can see the ~30% performance gain as well.

Hard coding all possible offsets below and doing all the buffer getting and writeBytes inline with those hard coded offsets I don't think is a good idea. This blows up the method size significantly for a tiny saving in CPU when it comes to evaluating the loop.

I benchmarked both this version and:

    public void writeVInt(int i) throws IOException {
        if (Integer.numberOfLeadingZeros(i) > 24) {
            writeByte((byte) i);
        } else {
            final byte[] buffer = scratch.get();
            int index = 0;
            do {
                buffer[index++] = ((byte) ((i & 0x7f) | 0x80));
                i >>>= 7;
            } while ((i & ~0x7F) != 0);
            buffer[index++] = ((byte) i);
            writeBytes(buffer, 0, index);
        }
    }

and I can't see statistically significant difference so that's not worth the complication IMO.

I would in fact expect the above version with the loop to be faster than what is in this PR in the real world because the smaller method size has a better better chance of getting inlined in some places (73 vs 507 bytes on JDK14/Linux for me).

I suppose you could work around the code bloat by doing this:

        final int leadingZeros = Integer.numberOfLeadingZeros(i);
        if (Integer.numberOfLeadingZeros(i) > 24) {
            writeByte((byte) i);
        } else {
            final byte[] buffer = scratch.get();
            final int length;
            switch (leadingZeros) {
                case 24:
                case 23:
                case 22:
                case 21:
                case 20:
                case 19:
                case 18:
                    buffer[0] = (byte) (i & 0x7f | 0x80);
                    buffer[1] = (byte) (i >>> 7);
                    assert buffer[1] <= 0x7f;
                    length = 2;
                    break;
                case 17:
                case 16:
                case 15:
                case 14:
                case 13:
                case 12:
                case 11:
                    buffer[0] = (byte) (i & 0x7f | 0x80);
                    buffer[1] = (byte) ((i >>> 7) & 0x7f | 0x80);
                    buffer[2] = (byte) (i >>> 14);
                    assert buffer[2] <= 0x7f;
                    length = 3;
                    break;
                case 10:
                case 9:
                case 8:
                case 7:
                case 6:
                case 5:
                case 4:
                    buffer[0] = (byte) (i & 0x7f | 0x80);
                    buffer[1] = (byte) ((i >>> 7) & 0x7f | 0x80);
                    buffer[2] = (byte) ((i >>> 14) & 0x7f | 0x80);
                    buffer[3] = (byte) (i >>> 21);
                    assert buffer[3] <= 0x7f;
                    length = 4;
                    break;
                case 3:
                case 2:
                case 1:
                case 0:
                    buffer[0] = (byte) (i & 0x7f | 0x80);
                    buffer[1] = (byte) ((i >>> 7) & 0x7f | 0x80);
                    buffer[2] = (byte) ((i >>> 14) & 0x7f | 0x80);
                    buffer[3] = (byte) ((i >>> 21) & 0x7f | 0x80);
                    buffer[4] = (byte) (i >>> 28);
                    assert buffer[4] <= 0x7f;
                    length = 5;
                    break;
                default:
                    throw new UnsupportedOperationException(
                            "Can't encode [" + i + "]. Missing case for [" + Integer.numberOfLeadingZeros(i) + "]?"
                    );
            }
            writeBytes(buffer, 0, length);
        }

but I can't measure a performance difference to the loop at all so personally I'd go for the shorter loop just for simplicity's sake.

[nik9000]

I think your right about your implementation being faster in practice. I put together a quick and dirty benchmark for writeVInt directly and my hand unrolled thing is faster there. By a pretty wide margin. But the benchmark for serializing the agg result is slower. I can see in the decompiled output that my method results in writeVInt not being inlined because it is too big like you say. And yours gets it inlined.

Optimize for size
Benchmark                                        (buckets)  Mode  Cnt   Score   Error  Units
StringTermsSerializationBenchmark.serialize           1000  avgt   10  59.064 ± 0.360  ms/op
StringTermsSerializationBenchmark.serializeVint       1000  avgt   10  17.211 ± 0.088  ms/op

Unroll loops
Benchmark                                        (buckets)  Mode  Cnt   Score   Error  Units
StringTermsSerializationBenchmark.serialize           1000  avgt   10  61.560 ± 0.124  ms/op
StringTermsSerializationBenchmark.serializeVint       1000  avgt   10  11.775 ± 0.048  ms/op

Unroll loops with if instead of switch
Benchmark                                        (buckets)  Mode  Cnt   Score   Error  Units
StringTermsSerializationBenchmark.serialize           1000  avgt   10  60.794 ± 1.069  ms/op
StringTermsSerializationBenchmark.serializeVint       1000  avgt   10  17.703 ± 0.075  ms/op

Compromise
Benchmark                                        (buckets)  Mode  Cnt   Score   Error  Units
StringTermsSerializationBenchmark.serialize           1000  avgt   10  62.106 ± 0.173  ms/op
StringTermsSerializationBenchmark.serializeVint       1000  avgt   10  16.425 ± 0.033  ms/op

The compromise solution doesn't seem to shrink the method enough.

[original-brownbear]

Thanks for testing this!

[nik9000]

I think we probably don't want to keep this benchmark but I pushed it so you could see what I was using for the numbers I shared.

[original-brownbear]

LGTM (excluding the vint benchmark, that doesn't really add much in isolation due to method size effects)