Ticket #9409 (assigned)
Improve PropertyHistory performance
| Reported by: | Samuel Jackson | Owned by: | Nick Draper |
|---|---|---|---|
| Priority: | major | Milestone: | Release 3.5 |
| Component: | Framework | Keywords: | |
| Cc: | Blocked By: | #8913 | |
| Blocking: | Tester: |
Description
PropertyHistory can give very slow performance as it has to convert properties to a string representation. For example, the CreateWorkspace algorithm will convert the vectors passed to it to a string (which also gets saved in the Nexus file). We need to find a way to improve the performance.
Change History
comment:2 Changed 6 years ago by Owen Arnold
- Status changed from new to infoneeded
Can you specify some more about the problem? Does this relate to code that has/is about to go into master? If the code that is causing bad performance has not yet made it to master, would be better not to allow it to if a problem has already been identified. What is currently affected by the poor performance?
comment:3 Changed 6 years ago by Owen Arnold
- Owner changed from Samuel Jackson to Owen Arnold
Can you specify some more about the problem? Does this relate to code that has/is about to go into master? If the code that is causing bad performance has not yet made it to master, would be better not to allow it to if a problem has already been identified. What is currently affected by the poor performance?
comment:5 Changed 6 years ago by Samuel Jackson
This is partly related to the changes to algorithm history in that it could make the performance worse as we're able to record more information about child algorithms. However, the unit/performance test results are largely unchanged by the new implementation.
This issue already existed in Mantid but may be compounded by the history changes. For example, the CreateWorkspace algorithm can take a long time to create its history record as it potentially has to convert large vectors of numbers to strings which are stored in PropertyHistory. So in the new implementation if we have a DataProcessorAlgorithm with lots of child CreateWorkspace calls it will increase execution time of that workflow.
In short, we don't have bad performance yet, but there are situations which could cause bad performance if left un-tackled. As nested history is not the cause of this problem I thought it could possibly be split into a separate ticket.
comment:8 Changed 6 years ago by Samuel Jackson
- Milestone changed from Release 3.2 to Release 3.3
Won't have time to do this for this release. Move to Release 3.3.
comment:11 Changed 5 years ago by Nick Draper
- Milestone changed from Release 3.4 to Release 3.5
Moved to R3.5 at the R3.4 code freeze
comment:12 Changed 5 years ago by Stuart Campbell
This ticket has been transferred to github issue 10252
