Hi Thomas,
I think you are right on. Before more discussion on GetBranch, I also noted that there is an increase in SetAddressImpl and this one was fixed by commit c2594baf41aea6bf25fbc7bfb65ee32058fed9a3 which will be part of v6.22/08.
To test you hypothesis without recompiling ROOT, there is 2 similar solutions. One requiring only code changes and one that is a long terms solution.
Code change only.
Replace tree->GetBranch(branchname) with tree->GetListOfBranches()->FindObject(branchname) with the caveat that the name now needs to be exact (including the presence or absence of trailing dot) and need to cast the result to TBranch.
Also replace tree->SetBranchAddress(....) with the same branch lookup and a call to SetAddress.
Long term solution.
Call SetBranchAddress (now with 3 arguments) or GetBranch only once per TTree per branch and cache the TBranch pointer. Note: when using a TChain and SetBranchAddress(const char *bname,void *add, TBranch **ptr = 0), the TChain will update the TBranch pointer whenever it is called.
Then use the TBranch pointer to call SetAddress rather than SetBranchAddress.
Alternate long term solution (probably impractical but potentially the most efficient)
Instead of keep a pointer to the branch, you could keep a pointer per branch used to communicate the address of the data to branch. You can still destroy and recreate the object after each event but keep the pointer to stable. For example if you know the number of branches before hand you could have a simple vector<void*> that you resize to that number of branches and where you did
m_datatree->SetBranchAddress(name.c_str(), coll->getBufferAddress());
you would now do a one time:
m_datatree->SetBranchAddress(name.c_str(), &voidptr_vector[ index_of_branch] );
and for each event
voidptr_vector[ index_of_branch] = *(void**)coll->getBufferAddress();
or maybe just
voidptr_vector[ index_of_branch] = coll;
Final note
All 3 cases will reduce the total amount of work and thus to compare you will need to re-run with both 6.20 and 6.22 (and because of the other problem I noticed and mentioned earlier, v6.22 should still be slower but by much less. My guesstimate is that the slow down would be reduced by 2/3).
Cheers,
Philippe.