Here's some others which seem excessively slow.

• Four of the tests should be resolved by a couple of equalities and a couple of ORs. https://www.wikifunctions.org/wiki/Z14053

• not(not(input)) takes over 10 seconds to orchestrate!? https://www.wikifunctions.org/view/en/Z10811

apine opened https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/149

Do not resolve or validate languages on Z17s.

I think one reason these are slow is that we're resolving all the labels (Z11, Z12, etc.) inside of the argument internals. We never use this information in the orchestartor, so we can just stop resolving those labels. I tested with your not(not(input)) example; with this change, we save 7 calls to the wikilambda_fetch API. There's a lot of other stuff causing slowdown, but this was a really obvious source of latency. Let's see if the performance is better once that MR is merged and deployed.

ecarg merged https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/149

Do not resolve or validate languages on Z17s.

The immediate (possible) fix is now merged. I have moved this task to "To Deploy."

Because the task description is open-ended, I don't know what the completion criteria should be: system performance is something we'll probably always be tweaking. The current fix should address one source of slowness. I have added another performance-optimization task, as well.

Thanks for your work, it sounds like a good improvement. I look forward to testing it out.

Change #1017060 had a related patch set uploaded (by Jforrester; author: Jforrester):

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2024-03-05-140533 to 2024-04-04-132719

https://gerrit.wikimedia.org/r/1017060

Change #1017060 merged by jenkins-bot:

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2024-03-05-140533 to 2024-04-04-132719

https://gerrit.wikimedia.org/r/1017060

I see that not(not()) now takes about 6000ms, which is definitely better, but still not what I would hope for. I also note that currently all the tests on https://www.wikifunctions.org/view/en/Z13499 timeout. But these are pretty arbitrary standards/expectations, so it's hard to say if there are still vast improvements possible.