I would advise against reserving using some kind of guess. We don't really know what to guess, and we would still need one dynamic memory allocation per call. The other alternative, recycling the vector, doesn't require guessing and means there will be 0 allocations per call eventually. It may also give us better locality of memory access.


The number of reallocations that Florian mentioned will depend on the task. Our data was for miconic-strips task 8-4, using the astar(blind()) configuration.

Relatedly, one of the next largest callers of "operator new" in this experiment was the EvaluationContext cache. Recycling objects could also be useful for the evaluation context.

We gathered this data by looking at the callers and number of calls of operator new/delete with callgrind. This was quite interesting in general and it could perhaps be useful to identify a few other optimization opportunities there.

While investigating issue348, we saw that a significant part of the dynamic memory allocations in our code come from reallocating the vector of applicable operators (see msg9794). The vector is reallocated roughly 5 times during its life.

In this issue we want to try to either use reserve with a reasonable size or to reuse the complete vector from one expansion to the next. This should improve the speed of eager search by a small amount.