Changes between Initial Version and Version 3 of Ticket #1424
- Timestamp:
- 03/02/11 10:25:19 (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1424
- Property Summary changed from Performance issues when executing more than 17 algorithm clones to Performance issues when executing more than 17 algorithms
-
Ticket #1424 – Description
initial v3 1 When more than 17 clones of an algorithm are executed, most of the execution time is spent in `set_ExecutionContext` of `Operator` and `Parameter`, which leads to a significant slowdown.1 When more than 17 instances of an algorithm are executed, most of the execution time is spent in `set_ExecutionContext` of `Operator` and `Parameter`, which leads to a significant slowdown. 2 2 3 This behaviour can be reproduced by c loning an algorithm more than 17 timesand then execute them sequentially. After the 17. algorithm the execution time drops quickly, reaching 100X slowdown after ~36 algorithm executions. Further executions reduce performance even more.3 This behaviour can be reproduced by creating more than 17 instances of an algorithm and then execute them sequentially. After the 17. algorithm the execution time drops quickly, reaching 100X slowdown after ~36 algorithm executions. Further executions reduce performance even more. 4 4 5 5 The following log shows the execution times of a `GeneticAlgorithm` with `PopulationSize`=10 and `MaximumGenerations`=10, cloned and executed 50 times: … … 60 60 My tests showed that this effect only occurs if all the executed algorithms stay in memory. If the algorithm clones have no more references in memory, the garbage collector takes care of them and there is no performance issue. 61 61 62 To clarify: this has nothing to do with cloning. It also happens when all instances are created independently. 63 62 64 Steps to reproduce: 63 65 * Create an HL-Experiment
