In #74 it was noted that e2e tests are ignored as they are using too much memory. We need to figure out what causes them to use as much memory as they do. It would be preferable to do so Personally my top three lists of high memory usage is:
Refinement as a precondition checks for consistency of both the lhs and rhs before doing the refinement check. Consistency checks calls getNextTransitions on mostly the same states as refinement does. If possible consistency should be checked as the systems are being traversed when checking for refinement.
Long lived objects. When doing refinement we keep track of all the visited locations. This reference might be the only one to the object and for this reason we are keeping it alive. I think passed lists of locations and such should be of the identifiers of the objects we passed instead of a reference to it. If this is done then we might experience a decrease in memory and CPU usage. Memory will decrease because the GC can collect them. CPU will be used because the ID will most likely be a type which is quicker to check equality for.
Garbage collection. I think both the state and location class have many different places with short lived objects (Where they are only alive in a small span of the time). Object pooling will be beneficial in this case, and for "bulk" instantiation (Many instantiations instead of a single constructor call).
This issue is resolved when issues have been open for the most obvious for memory usage.
In #74 it was noted that e2e tests are ignored as they are using too much memory. We need to figure out what causes them to use as much memory as they do. It would be preferable to do so Personally my top three lists of high memory usage is:
getNextTransitionson mostly the same states as refinement does. If possible consistency should be checked as the systems are being traversed when checking for refinement.This issue is resolved when issues have been open for the most obvious for memory usage.