For such variables, the solver used to track the lower-bound, the upper-bound and the domain size to provide quick access to the domain size. This decision had however a significant impact in terms of memory usage. It requires to have an additional StoredInt per variable and for every bound change, 2 values where saved into the stack.
In this patch, the domain size is no longer stored but computed on demand. In terms of performance, getDomainSize() performs now 2 get() and one subtraction while it used to perform one get(). On the other side it saves one StoredInt, and only one value is saved into the stack when a bound is updated.
After some internal experiments on (packing and scheduling) problems having around 100,000 bounded variables and 50,000 enum variables, this reduces the memory consumption of my JVM by about 30% with no performance degradation.
For such variables, the solver used to track the lower-bound, the upper-bound and the domain size to provide quick access to the domain size. This decision had however a significant impact in terms of memory usage. It requires to have an additional StoredInt per variable and for every bound change, 2 values where saved into the stack.
In this patch, the domain size is no longer stored but computed on demand. In terms of performance, getDomainSize() performs now 2 get() and one subtraction while it used to perform one get(). On the other side it saves one StoredInt, and only one value is saved into the stack when a bound is updated.
After some internal experiments on (packing and scheduling) problems having around 100,000 bounded variables and 50,000 enum variables, this reduces the memory consumption of my JVM by about 30% with no performance degradation.