[tree] Enable TTreeCache even if fAutoFlush == 0#8714
[tree] Enable TTreeCache even if fAutoFlush == 0#8714eguiraud merged 3 commits intoroot-project:masterfrom
Conversation
|
Starting build on |
|
Build failed on ROOT-debian10-i386/cxx14. Errors:
Failing tests: |
Yes, you could use the |
|
The median will still leave many clusters out (it only guarantees that 50% of them will be in, right?). How about the mode? |
|
Yes, I agree that the mode, when well defined would be better (As a aside the median an match more than 50% of the cluster, as is the case in the example file you had [where actually the mode and the median are the same]). By "well defined", I mean that if a large fraction of the file is not clustered (i.e result of the merge of many unclustered file and a few clustered files) then the 'mode' might not cover the majority of the cluster. I would say we could use "the mode or the median which ever cover more clusters and/or the largest fraction of the file", isn't it? |
Alright, can do that. But it's not super cheap, so I have two questions.
|
Humm .. i think it somehow get delegated to the underlying TTree.
it should be a one time (per TTree) cost in the case where the user did not specify the cache size and fAutoFlush is to zero (because after that the CacheSize is set)
I would do that. Thanks |
|
Latest hurdle: |
437d12d to
3339a51
Compare
|
Starting build on |
|
Build failed on ROOT-ubuntu16/nortcxxmod. Errors:
|
|
Build failed on ROOT-performance-centos8-multicore/default. Errors:
|
|
Build failed on mac11.0/cxx17. Errors:
|
|
Build failed on ROOT-debian10-i386/cxx14. Errors:
|
|
Build failed on mac1014/python3. Errors:
|
3339a51 to
f62bc1d
Compare
|
Starting build on |
|
Now, if |
f62bc1d to
2a56f48
Compare
|
Starting build on |
|
Build failed on ROOT-debian10-i386/cxx14. Errors:
|
2a56f48 to
58ab2da
Compare
|
Starting build on |
|
Build failed on ROOT-debian10-i386/cxx14. Errors:
|
We need to estimate this value to provides a reasonable cache size default if other heuristics fail.
With the previous logic, if for some reason fAutoFlush was set to 0 in a TTree, the TTreeCache ended up being disabled. That is undesirable: we still can and want to do pre-fetching even if auto-flushing was turned off when writing the TTree. Other more direct methods to turn off the TTreeCache still work, e.g. tree->SetCacheSize(0). This fixes root-project#8713.
58ab2da to
c67adf3
Compare
|
Starting build on |
Before this commit, when TTree::fAutoFlush == 0 **and fNClusterRange == 0**, the TTree cache size was set to 0, effectively disabling pre-fetching. With this patch we instead set the cache size to a reasonable default also in this case, assuming the default cluster size of ~30MB. This fixes root-project#8713 also for smaller files where fNClusterRange == 0.
c67adf3 to
945ed30
Compare
|
Starting build on |
With the current logic, if for some reason fAutoFlush is set to 0
for the TTree, the TTreeCache is disabled.
That is undesirable: we still can and want to do pre-fetching even
if auto-flushing was turned off when writing the TTree.
Other more direct methods to turn off the TTreeCache still work,
e.g. tree->SetCacheSize(0).
Checklist:
This PR fixes #8713 .