Title speed up blind search
Priority bug Status resolved
Superseder Nosy List jendrik, malte
Assigned To Keywords
Optional summary

Created on 2015-06-05.12:11:50 by jendrik, last changed by jendrik.

File name Uploaded Type Edit Remove
callgrind.out.airport-p24-astar-blind jendrik, 2018-03-16.19:17:43 application/octet-stream
msg9396 (view) Author: jendrik Date: 2020-07-02.00:09:49
I agree. Let's close this.
msg9395 (view) Author: malte Date: 2020-07-01.21:07:18
Compared to when we first opened this, we have much improved the successor generators, and your profile shows that the evaluation contexts that triggered this issue are not a bottleneck on the task that triggered this. So I don't think we have to consider this a "performance bug" any more. Since we have no concrete feature request, my recommendation would be to close this. What do you think?
msg6927 (view) Author: jendrik Date: 2018-03-16.19:17:43
I have done a profile for astar(blind()) and Airport #24. I aborted the run after 
400 seconds, but the data clearly shows that most of the time is spent generating 
applicable operators in the successor generator (82%). This should not have 
surprised me since I noticed earlier that random walks also take very long in 
Airport tasks.
msg6918 (view) Author: jendrik Date: 2018-03-16.17:29:01
We noticed in issue694 that a good test suite while making blind search faster 
could be the airport domain (see msg6916):

Malte: "I'm surprised to see the timeouts in airport, so I ran Airport #24
on my desktop at home (which is rather crappy, as it is designed not to require
a fan). It ran out of memory in 1000 seconds, which would mean that it is at
least roughly a factor of 2 faster, but I guess this is feasible, as I wasn't
using all cores concurrently and when we last compared desktop and server
machines, the single-core performance of the desktops was much better. Still,
I'm a bit surprised to see memory not being a bottleneck in blind search, and it
would be interesting to do a profile on such a problem at some point."
msg4610 (view) Author: jendrik Date: 2015-09-24.14:59:19
See also issue348.
msg4257 (view) Author: jendrik Date: 2015-06-05.12:11:50
The evaluation contexts introduced in issue77 made blind search significantly slower 
(see e.g. the relative scatter plot in issue77). We need to think about how we can make 
the procedure faster again. To evaluate success, we should do a comparison to a 
revision of the default branch that does not yet include the issue77 code.
Date User Action Args
2020-07-02 00:09:49jendriksetstatus: chatting -> resolved
messages: + msg9396
2020-07-01 21:07:18maltesetmessages: + msg9395
2018-12-03 11:36:18jendriksettitle: make blind search faster again -> speed up blind search
2018-03-16 19:17:43jendriksetfiles: + callgrind.out.airport-p24-astar-blind
messages: + msg6927
2018-03-16 17:29:01jendriksetmessages: + msg6918
2015-09-24 14:59:19jendriksetstatus: unread -> chatting
messages: + msg4610
2015-06-05 12:11:50jendrikcreate