Indeed, convert_global_state() is the culprit for blind search. I checked the impact of
issue511 and issue512 on the blind heuristic's memory and time usage and the
introduction of the State class (issue512) is accountable for almost the complete
difference on the tasks I checked.
For h^max and the two tested satisficing configurations the changes in time and memory
usage don't look great, but the results are more mixed than the ones for the blind
heuristic. Overall, I think the results are good enough to keep this as it is. Maybe we
can improve the timing and memory usage in issue348 again.
I see -- then I guess convert_global_state or a related method is the culprit
for blind search. Do you think the other results look good enough to consider
this done then? (I didn't look at all configurations in detail.)
Sorry, I forgot that the pull request shows only the changesets that were missing in the
default branch. Most importantly, the changes from issue512 (adding the StateProxy class) are
missing there. Here is the full diff for the two versions compared in the experiment:
https://bitbucket.org/jendrikseipp/downward/branches/compare/5c0efade9a57..3b077f064721#diff
I guess some of the performance penalty for the blind heuristic that we see here can be
explained by looking at the experiments from issue512. There we tested it on the
satisficing_with_ipc11 suite and it also became slower overall.
I really struggle to understand how this experiment can explain the almost
universal bad effect on blind search performance. Are these really the two
versions that were run? Were they run at the same time, with code compiled by
the same compiler versions etc., so that we can rule out an impact by factors
other than the code?
Can you point me to a diff for the configurations compared in the experiment?
There are some results I can't really explain, such as the consistently bad
results for blind search.
Hmmm, sorry to be late to the party, but I think this needs a performance test.
One basic configuration (A* or greedy search, depending on admissibility) for
each heuristic that uses this would be enough.
We'd like to remove the cost_type option in favor of two task transformations
that use unit costs and the original costs + 1. A first step towards that goal is
to add a task transformation that uses unit costs.