gripleaf opened a new issue, #240:
URL: https://github.com/apache/paimon-cpp/issues/240

   ### 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<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.
   
     2. Avro decoding calls `ArrayBuilder::type()` for every integer and 
timestamp value. Because this
        method returns `std::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!


-- 
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]

Reply via email to