Thanks to visit codestin.com
Credit goes to github.com

Skip to content

perf: replace protobuf metric reporting with pre-allocated flat long[] array#3614

Open
andygrove wants to merge 4 commits intoapache:mainfrom
andygrove:flat-array-metrics
Open

perf: replace protobuf metric reporting with pre-allocated flat long[] array#3614
andygrove wants to merge 4 commits intoapache:mainfrom
andygrove:flat-array-metrics

Conversation

@andygrove
Copy link
Member

@andygrove andygrove commented Feb 28, 2026

Which issue does this PR close?

N/A

Rationale for this change

I have been profiling with async-profiler and saw a surprising amount of time spent in metrics handling.

What changes are included in this PR?

  • Replace protobuf-based metric updates with a flat long[] array approach for faster native-to-JVM metric transfer
  • Pre-allocate parallel arrays (metric names, SQLMetrics, node offsets) at plan creation via DFS walk of CometMetricNode tree
  • Native side fills a Vec<i64> and copies to JVM via single SetLongArrayRegion bulk JNI call instead of protobuf encode/decode
  • JVM reads linearly from the array — no protobuf, no tree walking, no map lookups, no string allocations per update cycle
  • Remove metric.proto and all protobuf metric infrastructure

How are these changes tested?

…] array

Replace the protobuf-based metric update path with a flat array approach
for significantly faster metric transfers from native to JVM.

Previously, every metric update built a HashMap<String, i64> and
NativeMetricNode protobuf tree, encoded it, decoded on JVM side, then
walked the tree with Map.get() lookups per metric. Now, metrics are
flattened into parallel arrays at plan creation time, native fills a
Vec<i64> and copies to JVM via a single SetLongArrayRegion bulk JNI
call, and JVM reads linearly — no protobuf, no tree walking, no map
lookups, no string allocations per update cycle.
Metrics like conversionTime are accumulated on the JVM side and have
no native counterpart. Initialize the values array to -1 (sentinel)
and only update SQLMetrics where native actually wrote a value (>= 0),
preventing native metric updates from zeroing out JVM-accumulated
metrics.
@andygrove andygrove marked this pull request as ready for review March 2, 2026 15:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant