Issue675

Title reuse evaluation context
Priority wish Status resolved
Superseder Nosy List florian, jendrik, malte
Assigned To Keywords
Optional summary

Created on 2016-09-27.16:57:05 by jendrik, last changed by malte.

Messages
msg11222 (view) Author: malte Date: 2023-07-28.10:47:32
Closing this. Once we're further with the component interaction code and can hopefully simplify the design of the PerStateInformation class, a logical further step would be to improve the design of reuse in the evaluator computations, i.e., the task that is currently served by the EvaluationContext class. But I think this old issue is to unspecific to help us with this. I think what we really want is a redesign in the context of the new code architecture, but this will be another issue for another time.
msg5668 (view) Author: jendrik Date: 2016-09-27.16:57:05
Quoting Malte (https://bitbucket.org/jendrikseipp/downward/pull-requests/58/issue535/diff#comment-24332693):

"I think it's a good idea to avoid all the copying and merging of preferred operators that happens currently 
[...]. Not sure what the best place for the information to live is. Conceptually, it would make sense to me to 
store [preferred operators and similar information] in EvaluationContext and to make that class "resettable" 
(i.e., allow some form of assignment) so that every search engine can use a single reusable evaluation context 
rather than generating new ones all the time. The current code is quite wasteful w.r.t. performance, but we 
decided to live with for now because the old code was so broken and it's a step in the right direction."
History
Date User Action Args
2023-07-28 10:47:32maltesetstatus: unread -> resolved
messages: + msg11222
2016-09-27 16:57:05jendrikcreate