Change Details

Copied from original trac ticket: https://laura.hepforge.org/trac/ticket/48 As mentioned in https://laura.hepforge.org/trac/ticket/11#comment:27 there are still some large savings that could be made in the recalculation of the integrals. These should be investigated and implemented if feasible. The comment in ticket 11 was: One possibility to save a lot of time is to cache all the kinematics information for each grid point and for each event since approx 40-50% of the CPU time is in recalculating all the helicity angles, daughter momenta etc. from the two DP co-ordinates. We'd need to check the memory consumption very carefully but it could be a big saving. A further comment added to this ticket was: Caching the full kinematics will require moving the per-event information data members currently in LauKinematics into a POD object in order to minimise memory usage. LauKinematics can then own one of those objects (or even a pointer to one in order to avoid copying?). Should also try and reduce the memory consumed by other parts of the code - [ticket #14](https://laura.hepforge.org/trac/ticket/14) (now T39) should help with this. So these tickets should probably be addressed together.

Copied from original trac ticket: https://laura.hepforge.org/trac/ticket/48 As mentioned in [ticket #11, comment 27](https://laura.hepforge.org/trac/ticket/11#comment:27) there are still some large savings that could be made in the recalculation of the integrals. These should be investigated and implemented if feasible. The comment in ticket 11 was: One possibility to save a lot of time is to cache all the kinematics information for each grid point and for each event since approx 40-50% of the CPU time is in recalculating all the helicity angles, daughter momenta etc. from the two DP co-ordinates. We'd need to check the memory consumption very carefully but it could be a big saving. A further comment added to this ticket was: Caching the full kinematics will require moving the per-event information data members currently in LauKinematics into a POD object in order to minimise memory usage. LauKinematics can then own one of those objects (or even a pointer to one in order to avoid copying?). Should also try and reduce the memory consumed by other parts of the code - [ticket #14](https://laura.hepforge.org/trac/ticket/14) (now T39) should help with this. So these tickets should probably be addressed together.

Copied from original trac ticket: https://laura.hepforge.org/trac/ticket/48 As mentioned in [ticket #11, comment 27](https://laura.hepforge.org/trac/ticket/11#comment:27) there are still some large savings that could be made in the recalculation of the integrals. These should be investigated and implemented if feasible. The comment in ticket 11 was: One possibility to save a lot of time is to cache all the kinematics information for each grid point and for each event since approx 40-50% of the CPU time is in recalculating all the helicity angles, daughter momenta etc. from the two DP co-ordinates. We'd need to check the memory consumption very carefully but it could be a big saving. A further comment added to this ticket was: Caching the full kinematics will require moving the per-event information data members currently in LauKinematics into a POD object in order to minimise memory usage. LauKinematics can then own one of those objects (or even a pointer to one in order to avoid copying?). Should also try and reduce the memory consumed by other parts of the code - [ticket #14](https://laura.hepforge.org/trac/ticket/14) (now T39) should help with this. So these tickets should probably be addressed together.