Include only the name of operators in a run

[abeham]

When a run gets created the results are included as well as the parameters of an algorithm and a problem. If such a parameter happens to be an operator the operator is included in that run as a clone.

I think it should be enough if we only include the operator name. For analysis purposes in our RunCollectionViews only the name of the operator is important.

Is there a scenario where we need to store the operator as a full clone of its instance?

For a GA with 1000 Generations I compared the RunCollection when storing 100 runs (same run cloned 100 times) once with operator clones and once without. There is a reduction of 28% in compressed file size and 60% in uncompressed size, or in absolute terms from uncompressed 16.0 MB down to 6.3 MB. With the operators stored only as strings this number rises a little of course.

[abeham]

I looked a bit deeper into the issue examining the size of the serialized xml of a single run.

I took one run of the GA-TSP sample where Coordinates, DistanceMatrix, and BestSolution have not been collected. The run is copied to a run collection and saved. Then the operators are removed by a runcollection modifier, the modifier is removed and the run is saved again. These two are then compared:

• Including the operators has a total line count of 2029 compared to just 636 when operators are removed
• The Analyzer operator needs 1080 lines which is 53% of the whole file
  • in the Analyzer the biggest part is the BestAverageWorstQualityAnalyzer which has 32% of all the lines
• Selector, Crossover, Manipulator, SolutionCreator, Evaluator take together 17% of all lines
• So operators are contributing about 70% to the serialized xml size of this single run

However, the contribution to file size varies greatly between the operators, the range was [40;120] for the non-analyzer operators. A result of a single string uses just 4 lines, so there's quite some saving potential. I did not look into time differences.

[abeham]

Unfortunately it's not as easy to implement as I thought. CollectParameterValues is implemented in ParameterizedNamedItem which resides in HeuristicLab.Core. To add the name of an operator instead of the whole operator would require to create a new StringValue with the name, which in turn is a type of HeuristicLab.Data.

We could

• reimplement the functionality of CollectParameterValues anew in Algorithm, Problem and Operator and possible other types that are ParameterizedNamedItems and that can contain operators.
• add a method IItem GetCollectedValue() to IParameterizedItem or even IItem which returns this by default and which is overriden in Operator to return new StringValue(Name)
• delay the ticket and merge Core and Data

Other options?

[swagner]

Thanks abeham for your thoughts on this issue. We should spend some more time on discussing how to implement this. Therefore I move this ticket to 3.3.7 for now.

[abeham]

r7579: I solved this issue now. I found that CollectParameterValues was too monolithic in that you have to overwrite and re-implement the same method again if you wanted to change just a detail (in that case that operators are stored by their name). So I split CollectParameterValues into two separate logical parts:

• CollectParameterValues is iterating over the parameters
• GetCollectedValues decides what values are collected from the given parameter value

Algorithm and Problem now overwrite only GetCollectedValues, but reuse the implementation of the base class in that they only filter the values. When they see an IOperator they will instead convert it to its name. Using IEnumerable and yield I think that's a nice solution.

[abeham]

Please forward this to swagner when you've found no further issues.

[abeham]

I found a bug where parameters of the operators were not added to the run if the operator itself was not added to the run.

[abeham]

r7706: fixed bug in parameter collection

[mkommend]

Thanks for implementing this enhancement.