-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance: Skip duplicate candidates with IdentityHashMap and make AbstractEvolutionEngine thread safe #31
Comments
We fix that and improve evolution performance of the interface ... the same individual may potentially be selected more than once This has a consequence in which will then evaluate identical candidates more than once. The result is contention and reduced evolution performance which is a general problem not specific to any application. One gets partial relief by maintaining the fitness value in the candidate itself (not something that is always possible) and evaluating conditionally. That requires synchronizing on the candidate in The permanent solution is to only evaluate a reduced size set of distinct candidates. Synchronizing as described above is then no longer required. So in
and then in both single threaded and multi-threaded if branches replace and then later some post-processing to add the skipped duplicates back to the results so that the population size remains the same (that is why we count the duplicates):
Please refer to the attached source code. |
Shouldn't really be a problem with |
We can improve evolution performance of the
AbstractEvolutionEngine
by exploiting the specifiedSelectionStrategy
behavior.interface SelectionStrategy#select
comments:This has a consequence in
AbstractEvolutionEngine#evaluatePopulation()
which will then evaluate identical candidates more than once.
The result is reduced evolution performance which is a general problem not specific to any application.
One gets partial relief by maintaining the fitness value in the candidate itself (not something that is always possible) and evaluating conditionally. That requires synchronizing on the candidate in FitnessEvaluator#getFitness(). However, this scheme runs into thread contention problems with a high number of identical candidates, again resulting in reduced evolution performance.
The permanent solution is to only evaluate a reduced size set of distinct candidates. Synchronizing as described above is then no longer required.
So in
AbstractEvolutionEngine#evaluatePopulation()
and then in both single threaded and multi-threaded if branches
replace
for (T candidate : population)
with
for (T candidate : duplicatesCountMap.keySet())
and then later some post-processing to add the skipped duplicates back to the results so that the population size remains the same (that is why we count the duplicates):
Please refer to the attached source file
AbstractEvolutionEngine.zip
.
The text was updated successfully, but these errors were encountered: