Thanks Philippe, actually your solutions work for my example but the example is just a simplified version of my real problem. Anyway, I stubled on this post where a similar problem was posed and you proposed a solution leveraging friend trees and TTree::BuildIndex. This made me think about this possibility:
- create one tree per object, with a single branch holding that object. These trees have different number of entries, since for each event only a subset of objects may be available (and this subset can change from event to event)
- create an index tree with an entry for each event; this tree has one branch containing a list of integer indexes equal to the entry number in object trees of objects belonging to this event; a -1 index for a given object tree would mean that that object is not available for the current event
This is simple enough to guess that it would work even before having tried it, and would solve my problem and make me happy. I have only one concern: data will be split among different trees in the same file, and I read here that having one tree per object might impact I/O performance severely. That post is quite old but I assume it still holds, right? If so, maybe I can use a single tree with an index branch containing one entry per event and different branches for objects with different number of entries, to be read one by one according to index values for current event. But I fear that I/O problems will still be present with this approach. I don’t know how the Root I/O works at low level, so I’d need some guidance on this. Thanks.