Resetting ContentBuffer to its initial size

pbouda
pbouda Member Posts: 3 ✭
edited December 2023 in General Discussions #1
Hi all,

I have one dev-point regarding ContentBuffer. We try to minimize allocation rate and prefer bigger buffers to avoid their expension in case of bigger messages. It looks like the reset() function does not take into account the initial buffer size and works with the hardcoded value 4096bytes.

com.solacesystems.jcsmp.impl.ContentBuffer#DEFAULT_SZ

Would it be possible to change the behavior to respect the provided initial size?

Thanks a lot,
Petr

Comments

  • Ragnar
    Ragnar Member, Employee Posts: 65 Solace Employee
    #2

    Hello Petr,

    Can you provide more details on how your a setting a 'provided initial size'. ContentBuffer and DEFAULT_SZ are not part of the JCSMP exposed API. As a producer of messages, the application is entirely in control of the message size and backing buffers, so this parameter is not relevant.

    Are you trying to control how buffers are allocated for receive? What size messages do you expect to receive on average?

    There are some optimizations to avoid excessive reset() in the works already, but currently no plans to make it configurable. If we understood your use case better, we can consider it for a future release.

    Thanks,

    Ragnar

  • pbouda
    pbouda Member Posts: 3 ✭
    edited December 2023 #3

    Hello Ragnar,

    Thanks for you answer. Understood, I'll go deeper into the detail.
    First, I'm fully aware of using internal API (in the package "impl") and it's up to me to take a risk of changing the public methods :)
    My use-case: to avoid the allocation of buffers I created/cached in Thread-Local CustomJCSMPXMLMessage.

    CustomJCSMPXMLMessage.png

    Next I create our ContentBufferOutputStream:

    Screenshot 2023-12-20 at 7.56.22.png

    And then (removed details for the sake of simplicity):

    Screenshot 2023-12-20 at 7.38.46.png

    Very often we have 1MB message, 4MB in the extreme cases (in these cases I am OK with recreating the buffer in the reset message). 1MB buffer would cover all our cases, recreated 4kB buffer is unfortunately too small.

    Before and after the changes can be seen here (it's AsyncProfiler allocation flamegraph - it's based on JFR TLABs sampling), the purple color is HeapByteBuffer.<init>:

    Screenshot 2023-12-20 at 7.49.35.png
    Screenshot 2023-12-20 at 7.51.00.png

    In the most of out applications we went don't from 20-25% allocation rate to 5-10%. With setting the size of internal buffer to the original initial size (when the JCSMP message is created) we would eliminate the allocation of HeapByteBuffers completely.

    I know it's an internal API and you keep it this way, but it would be very helpful :)

    Thanks and regards,
    Petr

  • Ragnar
    Ragnar Member, Employee Posts: 65 Solace Employee
    #4

    Thanks Petr,

    We are aware of the excessive reallocations in JCSMP whenever a message is reset. The default size of 4096 is a hold-over from ancient days and is an arbitrarily small number in the modern world. We already have in development an API that only resets when the allocated buffer exceeds 100K.

    However based on your feedback, we're re-evaluating even that. We'll look at this more in January, with an eye to eliminating buffer reallocations or making it configurable. TBD. But we will be addressing this in the first quarter of 2024.

    Regards,

    Ragnar

  • pbouda
    pbouda Member Posts: 3 ✭
    #5

    Hi Ragnar,

    thanks for taking my case into your consideration. Please, let me know if you need any assistance or testing.

    In any case, wish all of you at Solace a Merry Christmas and a Happy New Year :)

    Best regards,
    Petr

Categories

This Month's Leaders

This Week's Leaders