Ticket #5727 (closed: wontfix)
Try to improve IntegratePeaksMD performance
| Reported by: | Russell Taylor | Owned by: | Russell Taylor |
|---|---|---|---|
| Priority: | major | Milestone: | Release 3.0 |
| Component: | Diffraction | Keywords: | Maintenance |
| Cc: | Blocked By: | ||
| Blocking: | Tester: | Michael Reuter |
Description
See if the performance hit described in ticket:4998#comment:8 can be reversed at least to some extent.
Change History
comment:2 Changed 8 years ago by Nick Draper
- Milestone changed from Release 2.4 to Release 2.5
Moved at the code freeze for release 2.4
comment:3 Changed 7 years ago by Russell Taylor
- Milestone changed from Release 2.5 to Release 2.6
Move the tickets I'm definitely not going to do this iteration so that I can better see the ones that I might.
comment:5 Changed 7 years ago by Nick Draper
- Milestone changed from Release 2.6 to Backlog
Moved to backlog at the code freeze for R2.6
comment:8 Changed 7 years ago by Russell Taylor
- Status changed from new to verify
- Resolution set to wontfix
I thought it might be down to the sin & cos calculations inside the tight loop in detectorQ, but when I pulled them out it made absolutely no difference. Probably, most of the time is in the ray tracing inside Peak::findDetector(). Assuming the behaviour of the algorithm is what's desired, there's probably not any large gain to be made.
N.B. There's another ticket (#5533) concerning the fact that OpenMP is currently turned off in this algorithm.
comment:9 Changed 7 years ago by Michael Reuter
- Status changed from verify to verifying
- Tester set to Michael Reuter
comment:10 Changed 7 years ago by Michael Reuter
- Status changed from verifying to closed
Sounds fine.
comment:12 Changed 5 years ago by Stuart Campbell
This ticket has been transferred to github issue 6573
Moved to milestone 2.4