Implements lazy buffer rotations

[mzimbres]

The read buffer won't rotate data if it can be increased without allocating more memory. The table below compares the performance before and after the changes

Strategy	time(s)	%usr	%sys	%CPU	rotation
Eager	92.22	67.37	2.92	70.29	6.7 Gbps
Lazy	91.16	60.15	2.82	62.97	99.0 kbps

The biggest gain in the benchmark above is in CPU usage because the overall time cannot be decreased much since the client is far from saturating the CPU.

[cppalliance-bot]

An automated preview of the documentation is available at https://415.redis.prtest3.cppalliance.org/libs/redis/doc/html/index.html

If more commits are pushed to the pull request, the docs will rebuild at the same URL.

2026-05-03 17:50:39 UTC

[anarthal]

Thanks. Will have a look soon.

[anarthal]

.

[anarthal]

Since GH seems buggy, I'll place my review in a comment to avoid losing it:

• https://github.com/boostorg/redis/pull/415/changes#diff-cf67e521e151f16e639d371d5b972fe0aa2eb6680a855608648b706adb456ed6R34: This is safer if written as buffer_.size() > cfg_.max_size - append_size; because buffer_.size() + append_size may technically overflow, leading to UB, while cfg_.max_size >= append_size should always hold (although I suggest adding a BOOST_ASSERT).
• https://github.com/boostorg/redis/pull/415/changes#diff-cf67e521e151f16e639d371d5b972fe0aa2eb6680a855608648b706adb456ed6R37: If erase() didn't really erase anything (because consumed_ == 0), rotated should be zero, rather than buffer_.size).
• https://github.com/boostorg/redis/pull/415/changes#diff-f3f96a8f99f99ba2e1ea212bd5387b46fd9e49460add831c3cbabf203f62b8fbR59: I don't think this is about right - the test should pass without reserving over the configured capacity (it defeats the purpose of a max capacity)
• https://github.com/boostorg/redis/pull/415/changes#diff-f3f96a8f99f99ba2e1ea212bd5387b46fd9e49460add831c3cbabf203f62b8fbR80: typo: consummed (should be consumed)
• https://github.com/boostorg/redis/pull/415/changes#diff-f3f96a8f99f99ba2e1ea212bd5387b46fd9e49460add831c3cbabf203f62b8fbR198: This should check capacity() to verify that we didn't realloc
• multiplexer::prepare_read() must not be noexcept, since it can trigger a realloc now.

[anarthal]

I've confirmed with vtune that the reader now takes less proportion of CPU time. Memmove no longer appears in the flame graph. Feel free to merge this when you want.

Something that'd be interesting is rewriting the read buffer without a vector, directly with a unique_ptr<char>. My experience is that this improves performance more than expected. But we can defer this to later.