Author malte
Recipients jendrik, malte
Date 2017-09-01.15:07:11
PS: the fact that we have long running configurations that spend more than 90%
of their time on dominance pruning suggests that we should look a bit more
closely whether dominance pruning is always a good idea, whether we should set a
time limit for it, etc. Can you open a separate issue for this? We might be
crippling our PDB-based planners in some domains. Woodworking with
astar(cpdbs(systematic(2))) would make a good test domain for this.

More generally, it is not ideal that we find out such bottlenecks more or less
by accident. Perhaps we can discuss how we can do things like these better in
the future, e.g. by having the results run include a categorical parameter that
explains what the bottleneck was and a numerical parameter that explains how
much time was spent on this bottleneck. To be really useful, this should also
adequately cover the case where we don't solve a task, i.e., where the
bottleneck leads to running out of time and memory. I think this shouldn't be
too difficult as long as the log output is clear enough to tell us at regular
checkpoints what the code is currently doing, at which point it started doing
it, and perhaps also what the peak memory usage at this point was.
Date User Action Args
2017-09-01 15:07:11maltesetmessageid: <>
2017-09-01 15:07:11maltesetrecipients: + malte, jendrik
2017-09-01 15:07:11maltelinkissue731 messages
2017-09-01 15:07:11maltecreate