Dear Epic support,
I have some simple questions to which I cannot seem to find complete answers.
I use a lot of EQS in my AI systems (with custom tests) and am starting to be worried about the performance impact they might have.
For instance one of these custom tests can take up to 1.6ms to complete (lots of points) and can be called multiple times.
I noticed there is a “can run async” checkbox in the main EQS window and when calling the test, we have to bind ourselves to a delegate to get the result (so all seems good for us to run this asynchronously right?)
All of that being said I can see in insight that there is still a cost of the EQS on the game thread (at least that’s what I believe). So I do have a few questions.
- Is it interesting to run explicitely the item iterator inside another thread ? (using the pipe job queue for instance)
- Is it interesting to use async trace ? Seems like a difficult situation considering the item iterator.
- Reducing the number of ms the EQS can take seems to not change anything, is this feature still working ?
- Any idea how I could reduce the impact ? I was thinking of reusing results but it’s a bit of a reach.
Thanks a lot !
So EQS is not currently multithreaded. There has been some prototyping around making it multithreaded, and we have long term plans to make an EQS 2.0 built on Mass. This work however does not have any targeted release and likely not to happen any time soon. The option for Can Run Async is only for use with MassEQS which is very experimental and has not seen any work in quite a while.
Are you running this on a dedicated server, client, or standalone? The value for MaxAllowedTestingTime should be respected. It does not immediately stop execution once the time has elapsed. If you look at UEnvQueryManager::Tick, it should run one execution step then reduce the time remaining. The time slicing is done by default in shipping and test builds, but you may check if it has been set to false in your project. You can also set whether you want to do work in breadth (run each query instance) or depth (run one query until it is finished).
Do you see any warnings in your logs for tests taking too much time to complete?
For improving performance, we recommend filtering using cheaper tests if possible and only run expensive tests at the end for scoring. EQS can auto-sort tests, but it would require that you have your custom tests marked with its cost.
-James
Thanks James for your answer, really insightfull.
I will be testing more with time slicing and monitor what’s happening.
That being said the fact that we are working in an asynchronous way sounded like a perfect place to go for multithreaded logics.
It seems impossible to do it within individual tests (because of the iterator - unless you have a trick (async trace for instance) ?) and sadly and I am not allowed to modify the engine. I also tried pre-batching result using a parallel for but didn’t seem to give me faster results. (for 3000 items)
By the way why is EQS an inner module when the editor side is a plugin ? I might be missing something.
Well either way, looking forward for more multi threaded things inside of the engine. thank you for mover 
The design makes it very difficult to run individual tests in parallel as EQS is designed to run the tests sequentially while filtering out items at each step. The best place to look for async query running is MassEQS inside the MassGameplay plugin.
I believe the editor is still a plugin because it is experimental and a pretty bad UX, but it works so it is hard to prioritize over new features.
Thanks James. I was more wondering about item slicing being async (each item goes through all tests asynchronously and stop at the first one failing it). This would have made more sense to me. And thus each individual test could handle item synchronously or not.
I will take a look at MassEQS but experimental is often a bad idea for productions ;D.
You are correct. MassEQS is not something I would recommend putting into production. I was suggesting to use MassEQS as a basis or example if you were going to try to make an async version of EQS.