-
Notifications
You must be signed in to change notification settings - Fork 146
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
Dev memo #964
Conversation
Step 1: `AbstractVariable`
…Constraints for the moment)
int nsize = ArrayUtils.newBoundedSize(last, from.length * 2); | ||
from = Arrays.copyOf(from, nsize); | ||
to = Arrays.copyOf(to, nsize); | ||
causes = Arrays.copyOf(causes, nsize); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
those refactoring seem a very good initiative
@@ -519,7 +522,47 @@ public ICause getCause() { | |||
return cause; | |||
} | |||
|
|||
static class BipartiteList { | |||
static abstract class ABipartiteList { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestions :
- externalize those classes to reduce file size
- it seems the abstract class has no field and could then be an interface with default implementation (the default implem could also be done as a separate class).
/** | ||
* Empty bipartite list | ||
*/ | ||
static final ABipartiteList EMPTY = new ABipartiteList() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the end the JVM will create an anonymous class, maybe we could have a proper class for the default case
Thank you for the review, I took your comments into account and move inner classes. |
…Selector when variables are added to constraint (like PropSat) during solving
Pull request has been modified.
/bench |
2 similar comments
/bench |
/bench |
/bench |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything is ok to me
This PR is ready to be integrated but I'm waiting for #993 to be fully merged to rebase this branch and provide some information related to the performance. |
Step 1: `AbstractVariable`
…Constraints for the moment)
…Selector when variables are added to constraint (like PropSat) during solving
…Selector when variables are added to constraint (like PropSat) during solving
# Conflicts: # parsers/src/test/resources/xcsp/instances.csv # solver/src/main/java/org/chocosolver/solver/search/strategy/selectors/variables/AbstractCriterionBasedVariableSelector.java # solver/src/main/java/org/chocosolver/solver/variables/impl/AbstractVariable.java
It appears that PR #889 has introduced a memory consumption issue.
Actually, the fact that propagators are not stored in an array (in
AbstractVariable
) but in an array of arrays requires too much memory.Here are the memory consumption (in GB), estimated with
Runtime
and validated with JProfiler, of dummy models only composed of a very big number (1000000) of variables but no constraint:Where
4.10.11*
denotes the proposal from this PR.The targeted class is
AbstractVariable
, and the idea is mainly to create structures only when required.The current way of storing a variable's propagators depends on the events they react on.
In many cases, all events are not really covered so there is no need to create everything all the time.
I also had a look to other array creation (in solver/, ignoring /constraints/ directory first).