I went over the pull request with Thomas and he was fine with all changes, so I
went ahead and merged this.

Good idea! I'll ask around.

Can you ask someone else for a look at the code and experiments? I think it's
good if we cultivate a culture of code reviewing and get more people to look at
more parts of the code. "Easy" code reviews are a good opportunity to get
practice with this.

I made a pull request at
https://bitbucket.org/jendrikseipp/downward/pull-requests/125 and ran an experiment:

https://ai.dmi.unibas.ch/_tmp_files/seipp/issue901-v2-issue901-base-issue901-v2-compare.html
https://ai.dmi.unibas.ch/_tmp_files/seipp/issue901-v2-plots.tar.gz

There are four configurations in thee experiment: {original,lm-goals}x{1M,900s}
original builds a single abstraction, lm-goals use landmark and goal
decompositions, the 1M configs limit the number of state-changing transitions by
1 million and the 900s configs limit time by 900 seconds. Note that the time
limit makes the latter configurations nondeterministic.

The memory score increases slightly for all configurations and the time scores
increase significantly. This leads to solving more tasks for 3 out of 4 configs.
original-900s profits the most from the change and solves 41 more tasks.

Do you want to have a look at the code? From my point of view, a review is not
so important here since all sanity checks are fine and the performance only gets
better.

I'm currently trying to store all nodes from the refinement hierarchy in a
vector and index them by IDs to avoid raw pointers and obtain better
cache-locality at the same time.

IIRC they are there intentionally because there is some sharing going on (ruling
out unique_ptr), but the semantics of what is shared are simple enough that the
ref-counting of shared_ptr would be unnecessary overhead. But perhaps we can
think of an alternative way to achieve the same thing.