The results look excellent, and the patch is fine.

And here is the plot for total time (description below).

Looks like this was worth the change: attached is a scatter plot of the search
time for the base version (09c98fa990c1) and a version with this fix
(23b21684dcb5). I'll attach a plot for the total time in a second post, because
I couldn't figure out how to attach 2 files in one post. Since the total time is
dominated by the pattern generation, the impact is much smaller on the total
time compared to the search time. It is still significant with 11 additional
tasks solved across 7 domains.

Gabi, could you review and pull this?
I uploaded it here
https://bitbucket.org/flogo/fast-downward/changesets/tip/branch%28%22issue367%22%29
(ssh access via ssh://hg@bitbucket.org/flogo/fast-downward with your bitbucket key)
Please only pull branch "issue367", as there are some other unfinished patches
in this repo.

> The idea was that "evaluate" is called once for each pattern, and the later
> parts of the computation then use "is_dead_end" and "get_heuristic", which just
> return a stored value.
In this case, it should be ok to check "is_dead_end" immediately (in the loop
over PDBs, not in the one over cliques) because the reaction doesn't depend on
the clique.

> Currently PDBs are evaluated during the loop over the cliques, so if
> a PDB is part of multiple cliques, is is evaluated multiple times.

Interesting, this is not how we wanted it. :-)

The idea was that "evaluate" is called once for each pattern, and the later
parts of the computation then use "is_dead_end" and "get_heuristic", which just
return a stored value.

Thanks for noticing this, definitely worth changing!

Gabi and I just looked at a small improvement for the CanonicalPDBsHeuristic:
When the heuristic value is calculated, we can evaluate each PDB before looping
over the cliques. Currently PDBs are evaluated during the loop over the cliques,
so if a PDB is part of multiple cliques, is is evaluated multiple times.
This change led to some improvement in the search time on the few samples we
tested on. 
The tests with dominance pruning (see issue350) suggest that this might also
have impact on the overall solve time in some domains.
I'm starting this issue mainly to get an issue number, so I can branch and test
properly.