wang-jiahua opened a new issue, #10969: URL: https://github.com/apache/rocketmq/issues/10969
### Before Creating the Enhancement Request - [x] I have confirmed that this should be classified as an enhancement rather than a bug/feature. ### Summary `PullAPIWrapper#processPullResult` re-stringifies `pullResult.getMinOffset()` / `getMaxOffset()` for every message in the batch, although both values are constant within one pull response. ### Motivation In the per-message loop, `MessageAccessor.putProperty(msg, PROPERTY_MIN_OFFSET, Long.toString(pullResult.getMinOffset()))` (and the MAX_OFFSET counterpart) allocates two new strings per message with identical content. A 32-message batch allocates 64 strings where 2 suffice; this runs on every pull response of every push/pull consumer. ### Solution Hoist the two `Long.toString` calls out of the loop and reuse the two strings for the whole batch. No behavior change: the property values are identical, `putProperty` semantics untouched. ### Verification - `PullAPIWrapperTest` 11/11 passed. - Joint benchmark on a 4-node cluster (producer 64 threads + consumer 20 threads, 1 KiB, consumer-side client jar swapped per arm, 3 interleaved 60 s trials): consumer young GC per million consumed messages 1.10/1.06/1.17 (base) vs 1.08/1.06/1.07 (patch), consume TPS flat — no regression. The allocation saving itself is small (tens of short-lived strings per batch) and below GC-count resolution; this is a trivial cleanup-level optimization on a hot path. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
