Make pruning much much less conservative

[jrapin]

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context / Related issue

Optimization may slow down dramatically at large number of iterations because the archive becomes big. this makes it much smaller.
The archive is therefore limited to 1000 points most of the time (more for large num_workers), which seems big enough in much cases

How Has This Been Tested (if it applies)

Checklist

• The documentation is up-to-date with the changes I made.
• I have read the CONTRIBUTING document and completed the CLA (see CONTRIBUTING).
• All tests passed, and additional code has been covered with new tests.

[jrapin]

@teytaud what do you think? I feel the archive is wasting time :s

[teytaud]

@teytaud what do you think? I feel the archive is wasting time :s

Ok my educated guess, taking into account the fact that the archive is the number of points, not the number of points with their repetitions, is something like "7 times num_workers should be enough" (or 7 times the population size); and possibly much more than that when we apply something like "clearing"...

but I might be completely wrong :-)

[jrapin]

@teytaud what do you think? I feel the archive is wasting time :s

Ok my educated guess, taking into account the fact that the archive is the number of points, not the number of points with their repetitions, is something like "7 times num_workers should be enough" (or 7 times the population size); and possibly much more than that when we apply something like "clearing"...

but I might be completely wrong :-)

If that fits 99% if use case then I go for it. This is only a default value, which can be modified by the optimizer if need be.