Cloning could be improved by creating objects at the bottom of the cloning chain with 'new' instead of the top with Activator.CreateInstance()

[gkronber]

implemented copy-constructor idea in a few of the core classes with r836.

[gkronber]

Refactored cloning in HL.Core, HL.Data and HL.Constraints with r885.

[gkronber]

Refactored cloning in all plugins except: HL.Communication, HL.Hive, HL.GP, HL.Routing, HL.Scheduling, HL.SimOpt, HL.Visualization with r887.

[gkronber]

Refactored cloning in plugins HL.Routing and HL.Scheduling with r888.

[gkronber]

fixed a few uninitialized fields with r889.

[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'.

[gkronber]

Killed the refactoring branch with r891.

[swagner]

Milestone 3.2 deleted

[swagner]

Milestone Iteration 0 deleted

[swagner]

Milestone Current deleted