xiangfu0 commented on PR #17605: URL: https://github.com/apache/pinot/pull/17605#issuecomment-5641830177
Revisited this proposal with measurements; the scoped follow-up is #19530. The iteration keeps only instance-config ID canonicalization at the enabled-server map boundary (one `intern()` per enabled server/config refresh). It omits the full IS/EV `internMapFields` traversal/rebuild and keeps the `ServerInstance` constructor/API unchanged. The evidence behind that scope: - Assignment server-ID keys were already canonical in the tested decoders: 300k assignment references used 100 ID objects before and after the original map pass. In the historical original-loop method-path benchmark, a 100k-segment/RF3 IS/EV pair incurred an extra **127–145 ms worker CPU and 32.8–37.2 MiB Java allocation**. That test uses JDK21.0.12 / Helix1.3.2 / Jackson2.21.0; it is separate from the newer follow-up measurements. - On the follow-up's JDK25 setup, 10k warmed map lookups/invocation improved from **39.50–40.42 µs to 15.37–15.45 µs**. This measures isolated elapsed lookup time, not broker CPU or production QPS. - The key-only implementation saves **0 or 88 bytes/server** in the tested retained-heap lifecycle. Increasing segments from 10k to 100k at fixed server count did not increase savings. Live `ServerInstance` values and old selector snapshots explain the zero-saving cases. - Both heap analyzers agreed across 108 main dumps and 30 fixed-seed controls (plus 12 lifecycle smoke JVMs). Matching Jackson symbol-table seeds resolved a separate ~3.18 MB cache-capacity discrepancy and reproduced both cache states on both revisions. [Decision rationale, raw refresh results, retained-heap proof and reproduction](https://gist.github.com/xiangfu0/8c696354ee5f35599792720c32a5d568#file-iteration-rationale-md). The follow-up is a small config-key lookup optimization. A material whole-broker footprint reduction, additional benefit from changing `ServerInstance`, and production-QPS/p99 gains remain unproven; those require separately scoped measurements. -- 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]
