I’m using a TTreeFormula in a loop over all entries of a TTree. At the moment i leave all branches enabled to ensure the formula has all inputs:
myQuasiCode(std::vector<TString> copyvars, std::vector<std::pair<TString,TString>> formulas) {
if (formulas.empty()) {
tree->SetBranchStatus("*",0);
for (auto var : copyvars) {
tree->SetBranchStatus(var,1);
}
} else {
/// TODO: do something smarter here
tree->SetBranchStatus("*",1);
}
std::vector<TTreeFormula*> m_formulas;
std::vector<float> m_formVars(formulas.size(),0.f);
for (size_t i = 0 ; i < formulas.size() ; ++i) {
m_formulas.emplace_back(new TTreeFormula(formulas[i].first.c_str(),formulas[i].second.c_str(),tree));
}
// then create a new tree with branches for all the variables which get copied, create branches for the formulas
for(int i = 0; i < tree->GetEntries(); ++i){
tree->GetEntry(i);
for (size_t i = 0 ; i < m_formulas.size() ; ++i) {
/// yes, I'm shadowing i here
m_formVars[i] = m_formulas[i]->EvalInstance();
}
// do all sorts of other stuff
}
So I’m looking for something like the following:
for (auto form : formulas) {
for (auto var: form.NeededBranches()) {
tree->SetBranchStatus(var,1);
}
}
(sure, var can be a branch of which i need to get the name… let’s call this a technical detail)
the main point is, the formulas come from elsewhere in the repository, or even code in another subpackage (assuming someone ever wants to reuse my code). the branches could be set at the place where the formula is defined, but … let’s say this is a job a computer should do much better: copying variable names out of a formula, without making typos, without forgetting the last variable, not taking into account that when changing “piplus_P” in the formula to “piminus_P” one also needs to update the list of branches … bottom line, i want the branches to switch on/off rather automatically for maintenance reasons.
[quote]So I’m looking for something like the following:[/quote]The good news is that this is superfluous.
[quote]bottom line, i want the branches to switch on/off rather automatically for maintenance reasons.[/quote]This already the case for TTreeFormula. TTreeFormula will explicitly read only the branches that are involved in the formula.
we’re talking about trees with >1M entries and somewhat between 1000 and 5000 branches of which the TTreeFormulas will need say less than 15 and the remaining code maybe 30. So i assume disabling the unneeded branches makes sense for performance reasons. And the number of needed branches is, I’d say at a level where bugs will be introduced if handled by hand, and a computer should be able to pick the branches very reliably (as we’ve just seen from the error message, ttreeformula is already able to detect that a necessary branch is disabled).
[quote]So i assume disabling the unneeded branches makes sense for performance reasons.[/quote]One genuine question is the performance of what.
Really, if all you use is TTreeFormula, you do not need to disable the branches and will still get maximum performance. TTreeFormula will only load/read the branches it needs and nothing else.
[quote]and the remaining code maybe 30.[/quote]For those case, I still prefer the direct approach, i.e. just call GetEntry on those 30 branches. If instead you use disable and TTree::GetEntry, one down-side is that the current code for each TTree::GetEntry will loop through all the branches to ask if they are enabled or not.
Cheers,
Philippe.
PS. The information you are asking about is (of course) available via TTreeFormula::GetLeaf which takes an integer from 0 to TTreeFormula::GetNcodes.
indeed i was unspecific. My main performance interest is time the programs takes, my guess is the limit is disk i/o. and i always had the impression (never measured it though) that looping over ttrees is faster when disabling unnecessary branches.
But that aside, I think filling a vector with all the Branches I need, to call GetEntry for the branches, is doable as well. At that point I stil need to know which Branches are needed by TTreeFormula, which GetLeaf - which you just pointed to - will provide.