A few questions on the Bulk I/O presentation.
- For the second 'GetEntriesFast', for returning the offset, maybe a simple array of long would be better (as the information is stored that way already in the TBasket in memory.
- Request of a benchmark also compare to SetBranchAddress/branch->GetEntry to compare with the current 'fast' path.
- Question on whether TTreeReaderFast ought to be a user level interface.
Brian answered that yes, this would allow the user to enforce the fast path and be clearly warned if it is not used. The only difference between the user code in this case and the regular TTreeReader ought to the same template name and we might even be able to find a solution to simplify the switch ... but we do have to keep it a compile time choice to allow for maximum performance.
It was also mentioned that TTreeReader might later take advantage of the TTreeReaderFast interface (and/or implementation) to speed up the case where it applies.
- Question on where this goes from there and in particular how to deal with it.
Brian mentioned that, once folded into the user code per se, the byte swapping time cost is not noticeable. This means that we might be able to get the effect of zero-copy even without changing the on file endianness.
To expand this to POD structs/class, we need to deal with padding, this might require a change of file format to include the padding on file.
Next Brian will look at better benchmarks and see if we can extend TFile to over a memory map interface over (some of) the files.
Zhe Zhang has made a merge request resolving outstanding issues in the parallel unzipping code and will be working on a TBB based reimplementation. He will cross check the known performance deficiency in order to able to address them in the new version.
We will have a meeting next week.
We will hold a ROOT I/O workshop on February 8th at 9am Chicago Time (16:00 Geneva time).
