Opened 13 years ago

Closed 12 years ago

Last modified 10 years ago

#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 12 years ago by gkronber

  • Owner changed from swagner to gkronber
  • Status changed from new to assigned

comment:2 Changed 12 years ago by gkronber

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

comment:3 Changed 12 years ago by gkronber

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

comment:4 Changed 12 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 12 years ago by gkronber

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

comment:6 Changed 12 years ago by gkronber

fixed a few uninitialized fields with r889.

comment:7 Changed 12 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 12 years ago by gkronber

  • Resolution set to wontfix
  • Status changed from assigned to closed

Killed the refactoring branch with r891.

comment:9 Changed 12 years ago by swagner

  • Milestone changed from 3.2 to Iteration 0

Milestone 3.2 deleted

comment:10 Changed 10 years ago by swagner

  • Milestone changed from Iteration 0 to Current

Milestone Iteration 0 deleted

comment:11 Changed 10 years ago by swagner

  • Milestone changed from Current to HeuristicLab 3.3.0

Milestone Current deleted

Note: See TracTickets for help on using tickets.