Ticket #1418 (closed: invalid)
Should we be recycling the objects we use in MRULists
| Reported by: | Russell Taylor | Owned by: | Russell Taylor |
|---|---|---|---|
| Priority: | minor | Milestone: | Release 2.2 |
| Component: | Mantid | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Tester: | Stuart Campbell |
Description
At the moment, when we use most recently used lists (MRUList class) we always create a new object of whatever is being stored in the list before inserting it and then delete the old object.
Can we just keep a constant set of objects in the list and just re-use them (i.e. put the new data into the object that's about to be taken off the list). This would avoid all this construction and destruction of objects and ought to be more efficient, though watch out for multi-threading issues (n.b. no multi-threading takes place when there's a managed workspace around, but it does with event workspaces).
Change History
comment:1 Changed 10 years ago by Nick Draper
- Owner set to Russell Taylor
- Status changed from new to assigned
- Milestone changed from Iteration 24 to Iteration 25
comment:2 Changed 10 years ago by Nick Draper
- Milestone changed from Iteration 26 to Iteration 27
Bulk move of tickets to iteration 27, if your ticket is essential for Iteration 26 then move it back.
comment:3 Changed 10 years ago by Nick Draper
- Milestone changed from Iteration 27 to Iteration 28
Bulk move of tickets at the end of iteration 27
comment:4 Changed 9 years ago by Nick Draper
- Milestone changed from Iteration 28 to Iteration 29
Bulk move of tickets at the end of iteration 28
comment:5 Changed 9 years ago by Nick Draper
- Milestone changed from Iteration 29 to Iteration 30
Accepted and assigned tickets moved at iteration 29 code freeze
comment:6 Changed 9 years ago by Nick Draper
- Milestone changed from Iteration 30 to Iteration 31
Bulk move of tickets to iteration 31 at the iteration 30 code freeze
comment:7 Changed 9 years ago by Nick Draper
- Milestone changed from Iteration 32 to Iteration 33
Moved to iteration 33 at iteration 32 code freeze
comment:8 Changed 8 years ago by Nick Draper
- Milestone changed from Release 2.1 to Release 2.2
Moved at end of release 2.1
comment:9 Changed 8 years ago by Russell Taylor
- Status changed from assigned to accepted
- Component set to Mantid
comment:10 Changed 8 years ago by Russell Taylor
- Status changed from accepted to verify
- Resolution set to invalid
Not really possible as the lifetimes of the held objects overlap, sometimes by a significant amount. In the case of managed workspaces all that's held now is a very small object pointing to where the data is anyway.
comment:11 Changed 8 years ago by Stuart Campbell
- Status changed from verify to verifying
- Tester set to Stuart Campbell
comment:13 Changed 5 years ago by Stuart Campbell
This ticket has been transferred to github issue 2265
This is worth looking into, I beleive we now have an MRU class, so if we can encapsulate the implementation in their all the better.