Is there an existing issue for this?
Current Behavior
Currently, there is a lot of time spent copying payload data.
Especially onerous is an entire copy made just to generate a crc32c of the payload.
Using the pack() / flush() API should be be more efficient.
Also, ByteBufferOutputStream copies incoming ByteBuffer contents to "pack" the data. Instead, the incoming ByteBuffers can be appended as-is.
Expected Behavior
No response
Steps To Reproduce
put a high volume of messages into a queue while using Java Flight Recorder to profile the method execution times.
BlazingMQ Java SDK Version
0.0.9
Anything else?
No response
Is there an existing issue for this?
Current Behavior
Currently, there is a lot of time spent copying payload data.
Especially onerous is an entire copy made just to generate a crc32c of the payload.
Using the pack() / flush() API should be be more efficient.
Also, ByteBufferOutputStream copies incoming ByteBuffer contents to "pack" the data. Instead, the incoming ByteBuffers can be appended as-is.
Expected Behavior
No response
Steps To Reproduce
put a high volume of messages into a queue while using Java Flight Recorder to profile the method execution times.
BlazingMQ Java SDK Version
0.0.9
Anything else?
No response