[Feature] Improve scan performance in hot read paths
@gripleaf is already working on this.
Since Sep 21, 2026.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- cpp
- Domain
- performance
Research direction
Start by profiling the manifest reader's StructArray::fields() calls and the Avro decoder's ArrayBuilder::type() calls in concurrent scan paths. Identify the appropriate batch, reader, or builder lifetime for immutable Arrow metadata, then verify caches are invalidated when the corresponding Arrow object tree is replaced. Done means reduced shared-pointer synchronization and reference-counting overhead under concurrent scans.
Written by the indexing model from the issue text.
Description
Search before asking
- I searched in the issues and found nothing similar.
Motivation
Recent profiling of highly concurrent scans has revealed several performance bottlenecks caused by
repeated operations on Arrow-returned shared_ptr objects in hot read loops.
Two significant cases have been identified:
-
Manifest readers repeatedly call
StructArray::fields()while processing individual rows. This
copiesshared_ptr<Array>objects and, with GCC 8.3's libstdc++, can introduce substantial lock
contention through_Sp_locker,pthread_mutex_lock, and futex waits when multiple workers read
manifests concurrently. -
Avro decoding calls
ArrayBuilder::type()for every integer and timestamp value. Because this
method returnsstd::shared_ptr<DataType>by value, concurrent scans repeatedly modify reference
counts on shared Arrow primitive data types, causing cache-line contention. Profiling showed
ArrayBuilder::type()and shared-pointer release operations accounting for a large proportion of
samples after the manifest bottleneck was removed.
This issue tracks the broader effort to identify and eliminate similar shared-pointer operations
from scan hot paths. The goal is to cache immutable Arrow metadata at an appropriate batch, reader,
or builder lifetime, while ensuring caches are invalidated whenever the corresponding Arrow object
tree is replaced.
The expected outcome is lower synchronization and reference-counting overhead under concurrent
scans, allowing CPU time to return to actual decoding, memory copying, and buffer management.
Solution
No response
Anything else?
No response
Are you willing to submit a PR?
- I'm willing to submit a PR!
- Dominant language
- C++
- Stars
- 65
- Forks
- 29
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 78
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/paimon-cpp
-
enhancement
apache/paimon-cpp#381 · 1 assignee ·
-
Difficulty 4/5 3-5 days Newbie friendliness 30/100
apache/paimon-cpp#375 · 1 assignee ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 45/100
apache/paimon-cpp#361 · 1 assignee ·
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 45/100
apache/paimon-cpp#325 · 1 assignee ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
apache/paimon-cpp#319 · 1 reaction · 1 assignee ·
All issues in apache/paimon-cpp
Similar issues
-
ai_reviewed
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
ydb-platform/ydb#53869 · 3 comments ·
-
bug cert blocker needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
project-chip/connectedhomeip#74373 ·
-
upstream update
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
conan-io/conan-center-index#31035 ·
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 85/100
vllm-project/vllm-ascend#17329 ·