#285 closed enhancement (rejected)
Cloning could be improved by creating objects at the bottom of the cloning chain with 'new' instead of the top with Activator.CreateInstance()
Reported by: | gkronber | Owned by: | gkronber |
---|---|---|---|
Priority: | medium | Milestone: | HeuristicLab 3.3.0 |
Component: | General | Version: | 3.2 |
Keywords: | Cc: |
Description
Change History (11)
comment:1 Changed 16 years ago by gkronber
- Owner changed from swagner to gkronber
- Status changed from new to assigned
comment:2 Changed 16 years ago by gkronber
comment:3 Changed 16 years ago by gkronber
Refactored cloning in HL.Core, HL.Data and HL.Constraints with r885.
comment:4 Changed 16 years ago by gkronber
Refactored cloning in all plugins except: HL.Communication, HL.Hive, HL.GP, HL.Routing, HL.Scheduling, HL.SimOpt, HL.Visualization with r887.
comment:5 Changed 16 years ago by gkronber
Refactored cloning in plugins HL.Routing and HL.Scheduling with r888.
comment:6 Changed 16 years ago by gkronber
fixed a few uninitialized fields with r889.
comment:7 Changed 16 years ago by gkronber
Looked into this feature and changed cloning in the core plugins for a test with OSGA on TSP problem. Made several observations:
- Almost all types in HL.Data don't call StorableBase.Clone() (which uses Activator to create new instances) and instead create the clone themselves. Thus, the most often used data-types are not affected by possible performance issues of Activator.CreateInstance
- XXXArrayData types are cloned via ObjectData which in turn calls Array.Clone()
- Operators do not override Clone and are cloned with Activator.CreateInstance. Thus, scenarios where Operators are copied frequently are relatively slow (MetaGP comes to mind). This issue can be solved by adding overrides for Clone in all Operators
- Adding overrides for Clone in all operators is takes a lot of time and severely deteriorates the codebase because each operator would need an empty Clone method (except for the constructor call, remember Operators must not keep internal state). Right now operators usually only need to override Apply and are thus very easy to write and understand.
- For the current applications (combinatorial opt. and GP) there is no performance gain. Neither combinatorial opt. nor GP clone items with Activator.CreateInstance heavily.
- However plugin developers should definitely keep in mind that StorableBase.CreateInstance should be used for convenience only and a custom override for Clone should be added for all data-types that are going to be cloned a lot (data held for individuals).
Based on those observations, mainly because of the insight that most of the core types already override Clone for performance reasons and that we would need to override Clone in all operators, we decided to close this ticket with 'wontfix'.
comment:8 Changed 16 years ago by gkronber
- Resolution set to wontfix
- Status changed from assigned to closed
Killed the refactoring branch with r891.
comment:9 Changed 16 years ago by swagner
- Milestone changed from 3.2 to Iteration 0
Milestone 3.2 deleted
comment:10 Changed 14 years ago by swagner
- Milestone changed from Iteration 0 to Current
Milestone Iteration 0 deleted
comment:11 Changed 14 years ago by swagner
- Milestone changed from Current to HeuristicLab 3.3.0
Milestone Current deleted
implemented copy-constructor idea in a few of the core classes with r836.