What/Why:
During follow-up investigation from this task, there was evidence that there were repeated/redundant calls made just within ZWrapper class during a single execute().
How:
Temporarily cache visited/'resolved' objects in a Map object and retrieve when needed and prevent duplicate logic.
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| Draft: memoize visited objects during execution | repos/abstract-wiki/wikifunctions/function-orchestrator!300 | ecarg | grace/T388075/temp-store-during-zwrapper | main |
ecarg opened https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/300
Draft: temporarily store visited objects during ZWrapper formation
I think I'll need to use request-id so that we can clear cache per unique call and then generate unique id's too per subcalls...
More things to consider:
organizing my thoughts:
Let's directly attach this to T390550: Implement Object and Wikidata entity batching mechanisms in the function-orchestrator to drive up user experienced performance when making function calls and reduce load on production wikis for now, ahead of having a tree.
I'm going to deprioritize this work as it is not majorly blocking a specific task and there are other tasks that can be more promptly resolved. This work is a sequence of new discovery, pivots, and demands careful thought; big time consumer, albeit non-trivial if succeeds.
Not sure if this should be marked as 'stalled' or 'invalid'. It's 'stalled' bc this is something we should implement (I tried incorporating memoization and that uncovered too many knots; not viable) in some way; perhaps using the new memcache? But this is 'invalid' in that the initial plan of attack proved unfeasible.