EngineAlgorithm should cleanup itself after it stopped

[cneumuel]

When an EngineAlgorithm stops, it currently keeps all its state-information (ExecutionContext and ScopeTree). This is unneccessary because when it is in ExecutionState "Stopped", it cannot be resumed (without calling Prepare, which causes the deletion of this state-information).

Problem: The state-information consumes a large amount of memory when beeing serialized, especially when the population size is large in evolutionary algorithms. This is a significant problem in Hive. When a finished algorithm contains tens or hundrets of megabytes of unnecessary information serialization, deserialization and transmission of jobs is unnecessarily slow.

Also, users who don't know the "trick" of calling Prepare before storing an algorithm, spend lots of unneccessary time on saving and loading their algorithms.

Just calling Prepare() when an algorithm stopped however would be too much, since this would cause the ExecutionTime and the ResultCollection beeing cleaned. It just would not fit the semantics of Prepare to use it for memory cleanup.

[swagner]

Implemented that the ExecutionStack (and consequently also all ExecutionContexts) is cleared in Engine, if the engine is stopped (see ticket #1333 and r5193).

[swagner]

Cleared global scope after an EngineAlgorithm is stopped in r5195.

[swagner]

Additionally, I think we should get rid of storing a clone of the algorithm in each run. This also requires a lot of memory which probably is not really worth it. I think that the feature to show the corresponding algorithm for a run is not really frequently used.

[cneumuel]

I agree that storing a clone of the algorithm in each run can become a huge memory-overhead. But maybe it would be enough to just make it an opt-in feature, rather than opt-out.

[cneumuel]

The following test shows that there may still be a problem with file sizes and memory consumption after the recent changes.

• Algorithm: Genetic Algorithm (MaxGenerations: 15, PopulationSize: 2000)
• Problem: Single Objective Testfunction (ProblemSize: 2000)
• StoreAlgorithmInEachRun: false

The following numbers show file-sizes when the algorihm is stored:

1. Before algorithm started: 37KB
2. After algorithm paused: 97MB
3. After algorithm stopped: 73MB
4. After algorithm prepared: 36MB
5. After clearing runs: 38KB!

The recent changes help to release ~24MB of memory when the algorithm stops, yet ~37MB can still be released by calling "prepare".

Also interesting and maybe a different problem is that by clearing the ResultCollection (which contained only 1 run), almost ~36MB of memory were released. I further investigated this issue and found that one problem might be the a SingleObjectiveTestFunctionSolution object contains a reference to the whole population. Therefore the BestSolution in a run also contains a reference to the whole population which in this case leads to a large memory consumption.

[swagner]

Changed storing the algorithm in each run into an opt-in feature in r5203.

[swagner]

Replying to cneumuel:

The following test shows that there may still be a problem with file sizes and memory consumption after the recent changes.

• Algorithm: Genetic Algorithm (MaxGenerations: 15, PopulationSize: 2000)
• Problem: Single Objective Testfunction (ProblemSize: 2000)
• StoreAlgorithmInEachRun: false

The following numbers show file-sizes when the algorihm is stored:

1. Before algorithm started: 37KB
2. After algorithm paused: 97MB
3. After algorithm stopped: 73MB
4. After algorithm prepared: 36MB
5. After clearing runs: 38KB!

The recent changes help to release ~24MB of memory when the algorithm stops, yet ~37MB can still be released by calling "prepare".

Also interesting and maybe a different problem is that by clearing the ResultCollection (which contained only 1 run), almost ~36MB of memory were released. I further investigated this issue and found that one problem might be the a SingleObjectiveTestFunctionSolution object contains a reference to the whole population. Therefore the BestSolution in a run also contains a reference to the whole population which in this case leads to a large memory consumption.

Yes, the large file sizes of case 3 and 4 result from storing the whole population in the SingleObjectiveTestFunctionSolution and consequently also in the BestSolution result (which is contained in the results as well as in each run). We decided to store the whole population in order to be able to visualize the whole population graphically. However, this is only possible in the 2D case. If the problem dimension is larger than 2, the graphical solution visualization is not available. Therefore, we should only store the whole population in the 2D case. I created a separate ticket #1360 for this issue.

[swagner]

Updated samples in r5205.

[cneumuel]

Tested the same algorithm with the recent changes:

1. Before algorithm started: 37KB
2. After algorithm paused: 105MB
3. After algorithm stopped: 84KB
4. After algorithm prepared: 64KB
5. After clearing runs: 38KB