231 low level: The map copy is a bit too expensive operation. A thin copy maybe could help, one which only adds/changes one or a number of values and otherwise relies on a base map
Generating all the possible steps for all the hosts / virtual machines / virtual disks is kind of a waste, but a subset would be enough on VM / host / network monitoring events trigger the planner. In such cases only the related VMs , hosts, etc would be included in the OperationalState.
234 fastpath factories: maintain an index of solutions for each kind of problem. When generating steps, first order the offered steps by the known solutions. With this, the subsequent planning runs can speed up, but they can still track back and find alternative solutions.
another kind of raw idea: incremental steps. After each step taken, we generate all the possible steps over again, even for objects that did not change. One could take the steps offered for the previous state for the objects that did not change
Right now step factories give a "hint": what problems or violations are they good against. It is purely for tuning, because planner would find these steps anyway. I could remove all these hints and instead just let the planner find what steps factories proved to be useful for certain types of violations and problems. This would mean a performance drop at the first planning iterations but very likely an increase in the later ones. This could also help code clarity.
Done
233 filter out repeating inverses: when the plan has already steps "power host-1 up" and then later "power host-1 down" then any new "power host-1 up" steps could be filtered out - and let's see how this effects performance
232 a simple one: I could collect the frequently used filters by step factories, refactor them in a method OperationalState and make it "lazy", this would avoid having to run the filter twice, but very likely only in the same state, after a step taken all these lazy states would be re-evaluated
Collection of ideas to improve the planner with:
231 low level: The map copy is a bit too expensive operation. A thin copy maybe could help, one which only adds/changes one or a number of values and otherwise relies on a base map
234 fastpath factories: maintain an index of solutions for each kind of problem. When generating steps, first order the offered steps by the known solutions. With this, the subsequent planning runs can speed up, but they can still track back and find alternative solutions.
Done
233 filter out repeating inverses: when the plan has already steps "power host-1 up" and then later "power host-1 down" then any new "power host-1 up" steps could be filtered out - and let's see how this effects performance
232 a simple one: I could collect the frequently used filters by step factories, refactor them in a method OperationalState and make it "lazy", this would avoid having to run the filter twice, but very likely only in the same state, after a step taken all these lazy states would be re-evaluated