I agree. Let's close this.

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?

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.

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."

See also issue348.

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.