[improve][java-client]Add init capacity for messages in BatchMessageContainerImpl

[AnonHxy]

Motivation

When adding messages to BatchMessageContainerImpl, it takes a lot of cpu time for the list growing of BatchMessageContainerImpl#messages, see below:

Modifications

• Init BatchMessageContainerImpl#messages with capacity.

Verifying this change

• Make sure that the change passes the CI checks.

Documentation

• doc-required
  (Your PR needs to update docs and you will update later)

• doc-not-needed
  (Please explain why)

• doc
  (Your PR contains doc changes)

• doc-complete
  (Docs have been already added)

Matching PR in forked repository

PR in forked repository: AnonHxy#3

[Jason918]

LGTM

[eolivelli]

LGTM

it is worth to cherry-pick this to branch-2.10 and branch-2.11

[AnonHxy]

/pulsarbot ready-to-test

[lhotari]

@AnonHxy just curious which VM/platform you are running on.

I'm wondering about the large portion of "gettimeofday" as part of the stack

Regarding "gettimeofday", there's a Brendan Gregg blog post "The Speed Of Time". In many cases, the fastest clocksource on Linux is tsc. GCP's GKE uses tsc by default.

Since Arrays.copyOf / System.arraycopy (or it's native implementations) don't seem to call gettimeofday at all, it might be GC related activity which is happening.

The default initial size for ArrayList is 10. In this PR it's changed to 64. That could make sense. However, I would assume that the average batch size is very rarely over 20, so this change won't make a difference in most cases. Since average batch size is rarely over 20, a better default could be a lower value, such as 32.

[lhotari]

the gettimeofday stack looks like MacOS, https://opensource.apple.com/source/xnu/xnu-3789.41.3/libsyscall/wrappers/__commpage_gettimeofday.c.auto.html
Profiling results can be flawed on MacOS.

[AnonHxy]

Profiling results can be flawed on MacOS.

Thanks for your reminder @lhotari , There is anothoer profiling result on Linux, the simiar conclusions can be drawn.

[AnonHxy]

Since average batch size is rarely over 20, a better default could be a lower value, such as 32.

It makes sense to me. Updated default capacity from 64 to 32. PTAL @lhotari

[lhotari]

Profiling results can be flawed on MacOS.

Thanks for your reminder @lhotari , There is anothoer profiling result on Linux, the simiar conclusions can be drawn.

Can you share the whole flamegraph? A lot of information is lost if you just provide a snippet of the whole graph.

[AnonHxy]

Can you share the whole flamegraph?

OK, here is the flamegraph file. @lhotari
buffer.html.zip

test case is below

public static void main(String[] args) throws Exception {
        String topic = "hxy-test-mem";
        byte[] smallMsg = new byte[64];
        PulsarClient client = PulsarClient.builder()
                .serviceUrl("pulsar://127.0.0.1:6650")
                .memoryLimit(2000, SizeUnit.MEGA_BYTES)  // memory limit 2000M
                .build();
        Producer<byte[]> producer = client.newProducer()
                .topic(topic)
                .enableBatching(true)
                .create();
        for (int i = 0; i < Integer.MAX_VALUE; ++i) {
            producer.sendAsync(smallMsg);
        }
    }

[AnonHxy]

/pulsarbot run-failure-checks