Slow REST data processing due to DIRC LUT

[aaust]

@ilyalarin reports that he observed an order of magnitude faster processing rates for REST files when he turns the calculation of the DIRC look-up-table off: -PREST:DIRC_CALC_LUT=0 (default 1)
I made a quick comparison on the ifarm with the the latest release 7.7.0. I used the monitoring_hists plugin and 20k events for file dana_rest_072058_010.hddm:

NTHREADS	Default Rate (Hz)	Rate LUT off (Hz)
1	151	760
2	258	892
4	393	794

For single-threaded processing, I see a factor of 5 speed up. The quoted rates for multithreaded processes likely are dominated by the thread initialization and would need larger samples.

Do we need this calculation by default? Should it be turned off when the DIRC PID information is already available in the REST file? Or can the performance of this calculation be improved?

[jrstevenjlab]

Good questions. We added this feature to the analysis of REST files, so that as DIRC reconstruction and performance improved we didn't have to go back to the raw EVIO files to improve the PID variables. When we're running a full list of reactions for analysis launch, I wouldn't expect this would be a limiting factor, but for other simpler processes, it is probably the largest consumer of CPU. Answers to your questions:

Do we need this calculation by default?

No, it doesn't need to be on by default if it's a significant slowdown for analyzers. Especially if you're not planning to use the DIRC information in analysis, then it's not relevant to improve their performance. So, its fine with me to turn it off by default, as long as we're ready to enable it for analysis launches and in simulation as needed.

Should it be turned off when the DIRC PID information is already available in the REST file?

No, if the DIRC PID information is available in the REST file, that is exactly the thing we want to overwrite by doing an improved LUT reconstruction during the analysis launch. The existing reconstruction in the REST file is likely not as high quality.

Or can the performance of this calculation be improved?

Good question, I'm not sure it's been fully optimized because I didn't think of it as being a bottleneck relative to many kinematic fits being applied for different reactions in the analysis launch. That said, if its limiting our analysis launch throughput, we should try to improve it.