[ISSUE #10969] Hoist per-batch constant min/max offset strings out of message loop in PullAPIWrapper - #10971
Conversation
There was a problem hiding this comment.
Pull request overview
This PR optimizes PullAPIWrapper#processPullResult by reducing per-message allocations when annotating pulled messages with batch-level min/max offsets, aligning with the hot-path allocation reduction described in Issue #10969.
Changes:
- Hoists
Long.toString(pullResult.getMinOffset()/getMaxOffset())out of the per-message loop. - Reuses the resulting
minOffset/maxOffsetstrings for all messages in the pull batch.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
RockteMQ-AI
left a comment
There was a problem hiding this comment.
LGTM. Clean optimization — hoisting the two Long.toString() calls out of the per-message loop is correct since pullResult.getMinOffset() and pullResult.getMaxOffset() are constant within a single pull response. Reduces unnecessary short-lived string allocations on a hot path with zero behavior change.
Automated review by github-manager-bot
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #10971 +/- ##
=============================================
- Coverage 48.58% 48.50% -0.08%
+ Complexity 13676 13653 -23
=============================================
Files 1381 1381
Lines 101475 101476 +1
Branches 13190 13191 +1
=============================================
- Hits 49299 49220 -79
- Misses 46174 46241 +67
- Partials 6002 6015 +13 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
…out of message loop in PullAPIWrapper
851b437 to
634e146
Compare
RockteMQ-AI
left a comment
There was a problem hiding this comment.
Summary
Hoists Long.toString(pullResult.getMinOffset()) and Long.toString(pullResult.getMaxOffset()) out of the per-message loop in PullAPIWrapper#processPullResult, since both values are constant within a single pull response. Also adds an isEmpty() guard to skip string allocation entirely when the filtered list is empty.
Clean, correct optimization. For a 32-message batch this eliminates 64 unnecessary short-lived string allocations per pull response.
LGTM.
Automated review by github-manager-bot
Which Issue(s) This PR Fixes
Fixes #10969
Brief Description
In
PullAPIWrapper#processPullResult, the per-message loop callsLong.toString(pullResult.getMinOffset())andLong.toString(pullResult.getMaxOffset())for every message, although both values are constant within one pull response. A 32-message batch allocates 64 identical short-lived strings where 2 suffice, on every pull response of every push/pull consumer.This PR hoists the two
Long.toStringcalls out of the loop and reuses the two strings for the whole batch. No behavior change: property values are identical andputPropertysemantics are untouched.How Did You Test This Change?
PullAPIWrapperTestpasses (11/11).