[ROOT-6103] TTreeCache broken for version >=5.34.11 Created: 21/Feb/14  Updated: 25/Mar/14  Resolved: 25/Mar/14

Status: Closed
Project: ROOT
Component/s: I/O
Affects Version/s: 5.34/00
Fix Version/s: None

Type: Bug Priority: High
Reporter: Guenter Duckeck Assignee: Philippe Canal
Resolution: Fixed Votes: 0
Labels: None
Environment:

lxplus


Attachments: Text File root_versions_tcache.txt     File tdraw.C    
Development:

 Description   

It seems TTreeCache is not properly caching, starting version 5.34.11.
I noted it when testing ATLAS D3PD analysis scripts. I can reproduce it with simple TTree:Draw example, see attached output of TTree::PrintCacheStats(); for 5.34.11 and 5.34.10 when executing attached script.
In case of TSelector type analysis 'Cache Efficiency Rel' is basically 0.
Problem seems still present in higher version, e.g. 5.34.14
cheers

Guenter



 Comments   
Comment by Philippe Canal [ 21/Feb/14 ]

Hi,

I am not able to reproduce your issue.

There ought to be slight improvement in some case in the TTreeCache between 5.34/10 and 5.34/11.

The TTreeCache is not enabled by default but your script does not enable it. How is it enable in your case?

Cheers,
Philippe.

Can you also post your data file?

Comment by Guenter Duckeck [ 22/Feb/14 ]

Hi Philippe,

the attached script should demonstrate the issue and run everywhere, and the file is also publicly readible via xrootd,
doesn't it work for you?

According to http://root.cern.ch/root/html534/TTreeCache.html "the TreeCache is automatically used by TTree::Draw. "
And that's what I observe.
It's enabled both for 5.34.11 and 5.34.10 but not effictive in the former case.

cheers

Guenter

Comment by Peter Van Gemmeren [ 10/Mar/14 ]

Hi Philippe,

I am able to reproduce Guenter¿s observation. The caching efficiency in 5.34.11 seems to have dropped, because only one (mu_staco_phi) of the two branches in:
T->Draw("mu_staco_phi:mu_staco_eta>>hist(100,-3.5,3.5, 100, -5,5)", "", "COLZ");

Were added to the cache. In 5.34.10 both variables were cached. Guenter¿s example uses learning on 100 events to determine the variables to be cached. Without looking into the any closer, I wonder, whether this could be related to:

http://root.cern.ch/gitweb?p=root.git;a=commitdiff;h=475165c0e15ed5019c2ce675650435b829d0a03f

(that is only a shot in the dark, I have not yet followed through the call sequence at all).

Cheers, Peter

Comment by Philippe Canal [ 25/Mar/14 ]

Thanks for you report, this problem has been resolved in the master and v5-34 patch branch (and will be part of v5.34/19).

Cheers,
Philippe.

Generated at Tue Sep 24 10:46:56 CEST 2019 using Jira 7.13.1#713001-sha1:5e06076c2d215a6f699b7e5c90ab2fae7ba5a1ce.