xiangfu0 commented on code in PR #19914:
URL: https://github.com/apache/pinot/pull/19914#discussion_r4301006282
##########
pinot-core/src/main/java/org/apache/pinot/core/common/ObjectSerDeUtils.java:
##########
@@ -1366,20 +1367,33 @@ public Geometry deserialize(ByteBuffer byteBuffer) {
@Override
public int getSerializedSize(RoaringBitmap bitmap) {
+ // Run containers allocate typed views when writing directly, so the
heap serializer is cheaper.
+ if (bitmap.hasRunCompression()) {
+ return -1;
Review Comment:
Addressed in
[f26c5e7](https://github.com/apache/pinot/commit/f26c5e7fb60339bf2656b2cf8e42bf6b60475aac).
Every bitmap now returns its exact serialized size, so the mixed case stays on
the direct Arrow path. I removed the heap-preference policy after clean
measurements showed that even a 128-byte cap adds allocations for small
payloads. Exact sizing and the typed buffer writer match the direct base; the
heap completion guard remains.
Three forks/source on JDK 25 with #4759 at `abbe605`: the one-run/127-dense
fixture measures **1,041,605.58 → 97.43 B/row** versus the heap-preference
revision (direct base: **97.65**); the 117-byte, 1,024-row run fixture measures
**192.53 → 0.63 B/row**; the actual setter measures **192 → 88 B/call**.
One-row fill is **688.01 → 584.01 B/call**, with a remaining **+10.67 B/call
mean** against direct base from one +32 B fork; two match. All
fix-versus-direct timing intervals cross zero on the swapping host. The PR
descriptions contain the updated numbers and limits; all **514 focused tests**
and style checks passed.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]