Improve PropertyHistory performance

[mantid-builder]

This issue was originally TRAC 9409

Original Reporter: Samuel Jackson

This ticket is blocked by :

• TRAC8913

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.

[mantid-builder]

@OwenArnold (2014-05-02T14:04:07):
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?

---

@OwenArnold (2014-05-02T14:04:34):
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?

---

Samuel Jackson (2014-05-02T15:12:43):
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.

---

Samuel Jackson (2014-06-13T15:54:58):
Won't have time to do this for this release. Move to Release 3.3.

---

@NickDraper (2015-04-27T08:10:34):
Moved to R3.5 at the R3.4 code freeze

[NickDraper]

This has not proved a problem since