[Feature] Improve scan performance in hot read paths
- Vorherrschende Sprache
- C++
- Sterne
- 65
- Forks
- 25
- Ø Merge
- 2 T. 12 Std.
- Gemergte PRs (30 T.)
- 80
Beschreibung
### Search before asking
- [x] I searched in the [issues](https://github.com/apache/paimon-cpp/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:
1. Manifest readers repeatedly call `StructArray::fields()` while processing individual rows. This
copies `shared_ptr` 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.
2. Avro decoding calls `ArrayBuilder::type()` for every integer and timestamp value. Because this
method returns `std::shared_ptr` 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?
- [x] I'm willing to submit a PR!
Beitragsleitfaden
Rechercherichtung
Beginne damit, die Aufrufe von StructArray::fields() im Manifest-Reader und die Aufrufe von ArrayBuilder::type() im Avro-Decoder in parallelen Scanpfaden zu profilieren. Ermittle die passende Batch-, Reader- oder Builder-Lebensdauer für unveränderliche Arrow-Metadaten und überprüfe anschließend, dass Caches invalidiert werden, wenn der entsprechende Arrow-Objektbaum ersetzt wird. Erledigt ist die Aufgabe, wenn der Aufwand für die Synchronisierung von Shared-Pointern und die Referenzzählung bei parallelen Scans reduziert ist.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- cpp
- Bereich
- performance
- Issue-Typ
- Feature
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Aktivitätsstatus
- Aktiv
- Klarheit
- Muss geklärt werden
- Anfängerfreundlichkeit
- 35/100