New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize front-end processing time #37
Optimize front-end processing time #37
Conversation
jbsauvan
commented
Aug 23, 2016
- Reduce front-end processing time by a factor of ~1000-2000 for events without pile-up (from about 3min / evt to about 100ms / event, tested with particle guns).
- Only modules containing hits are processed, and hits in each module are preselected before the codec is called.
- It removes a double loop on all modules + all hits and replace it with a single loop on all hits followed by a double loop on selected modules and associated hits.
} | ||
const auto& module_ptr = triggerGeometry_->modules().at(module_hits.first); | ||
// Association simhit energies with trigger cells | ||
std::map<uint32_t, double> TC_simhit_energies; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unordered_map
Thanks @lgray. |
std::unordered_map<short, short> wafer_to_module_ee; | ||
std::unordered_map<short, short> wafer_to_module_fh; | ||
std::unordered_map<short, std::unordered_map<short,short>> module_to_wafers_ee; | ||
std::unordered_map<short, std::unordered_map<short,short>> module_to_wafers_fh; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the code below it looks like you can just use std::unordered_multimap<short, short>, which would be more compact in memory and faster. Any reason why not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually it just reminds me that I need an ordered iterator for the second map, e.g. line 107 (but not for the first one), so I would need unordered_map<short, map<short,short>> (or multimap<short, pair<short,short>> should work as well, but would probably be slower when searching for a module line 132).