202nd ROOT Parallelism, Performance and Programming Model Meeting
ROOT PPP 03.09.2026
-
[Stephan]: Are the RNTupleProcessor classes polymorphic?
- Yes
-
[Stephan]: when you create a combined processor, do you need to give ownership of the input processors to the combined one?
- Yes, all constructors accept std::unique_ptr. This is done to avoid inconsistencies while processing events (the driver of the loop is the "main" processor (i.e. the leftmost one in the combination)).
-
[Martin]: How many columns can you join on?
- Up to four
-
[Philippe]: Do you have a clone/copy mechanism?
- Not yet
-
[Philippe]: The current processor number, or the equivalent in TChain is used for two completely different purposes: one is to detect a file transition, the other is to know which is the current file if the user want to do something different depending on that.
- For the first case, that's an internal thing now and doesn't need to be public, the second one could be a use case
- [Jakob] but the underlying item is not a file now, it's another processor, so the semantics are unclear.
-
[Philippe] what is the difference between GetCurrentEntryNumber and GetNEntriesProcessed?
- For now, nothing. But for example in MT scenarios they could be different
- [Vincenzo] or also if we allow sparse reading
-
[Jakob] I think we should start with all private interfaces except those for which we have evidence that it's necessary
-
[Philippe]: Having to advance an iterator for a million events is more expensive than the user telling us they want to go to entry one million, in the latter case we can just skip entire files.
-
[Jakob/Stephan]: Maybe not loading random entries but advancing by more than one entry sounds like an important feature.
- [Stephan] your iterator could accept an integer such that calling std::advance on it could make it jump by that number.
-
[Vincenzo]: What happens with BindRawPtr?
- This introduces some unsafety.
- [Vincenzo]: could we also have a std::shared_ptr interface?
- [Jonas]: depends on what use case we want to cater, shared_ptr may have some benefit
-
[Vincenzo]: how thorough is the tracking of fields in the datasets of the internal RNTupleProcessorEntry? For example, I have two chains and I join them together. A certain column x is present now in a file of the left chain and then in a file of the right chain
- [Philippe] the use case defined above may actually exist, we have seen this in TTree.
- [Vincenzo] I believe with a carefully crafted set of join and chain combinations, this could work with the RNTupleProcessor but only if we relax the requirement of the auxiliary dataset prefix
- [Florine] I'll get to that later, but also I don't like anything about this use case.
- [Jakob] I would at least note it down, maybe it's an advanced use case but doesn't sound completely crazy to me.
-
[Stephan]: naming of the kUseAuxPrefix flag, maybe we can change it to something more clear to users
- Like kRequireAuxPrefix
- [Jonas] For example kLazyNameMatching
-
[ Jonas] coming back to that situation above, should we check in all processors or just in the first set?
- Currently it checks only in the first RNTuple, maybe we can add a deep search?
- [Jonas] I'm worried about the fact that if you specify the prefix, for that case the order doesn't matter
- [Jakob] Couldn't we have something like an alias definition or a rename definition? For this particular processor instance, that field is called something else
- Whats the benefit?
- [Jakob] I'm wondering if we could have a more general interface that lets us as a side effect disambiguate better.
- [Stephan] I don't see how the renaming would make things safer.
- [Jakob] For these advanced use cases, we should avoid designing API such that it forbids the use case altogether.
-
[Stephan] Checking name conflicts sounds like you have to check the entire chain a priori, can you do it on file change?
-
[Vincenzo] I wanted to ask for a clarification about the use case, my understanding is this is done for when the user expects a certai column name to be there, irrespectively of whether there are multiple joins, or whether there was a previous processing that led to merging fields and having one RNTuple on disk with the column already available
- Yes
-
[Jonas] For final point 4, that also includes persistifying join table?
- At some point, it's a separate point I didn't include.
- [Philippe] persistifying the table is "trivial"
- Not sure if it is