Async support about urho HOT 1 OPEN

I have an observation that is this topic related. I've been testing actions in Urho in order to implement logic for my actual project. What I need is an ability to write asynchronous code in order to simulate a lot of objects, let's say thousands.

Unfortunatelly the performance of actions for such purposes is not good enough. My test was set up with a simple scene with a lot of nodes, each of them having attached a component which started some tasks, continuously repeating them. The performance hit was tremendous when delays between tasks were small, e.g. tens or hundreds of miliseconds. I checked two approaches, with DelayTime which is an Urho action, and even with native Task.Delay.

I was trying to improve the overall solution by implementing synchronization context which executed tasks during update event, but it didn't help at all. The next approach was with a custom task scheduler which was processing tasks in a thread. Although there were no framerate drops anymore, tasks couldn't be processed "on time", making small delays lasting more than they should do.

The problem is that it is a very time consuming to call all of these queued callbacks if delays are small. There is still a possibility that I am doing something wrong or do not completely know how to handle it correctly. But, anyway, I figured out how it could be solved without tasks, but still with an asynchronous support for logic of my project.

I simply created a component which processes Func<float, bool> delegates. The delegate takes delta time as an input parameter and returns bool whether it should be treated as finished or not. Queued delegates are processed in an update event. If they are finished, they are removed from collection.

It is quite easy to implement behaviors like a Sequence, WhenAll or WhenAny. Sequence has an internal list of mentioned delegates and advances actually processed delegate, returning true only if all of them were finished one by one. WhenAll runs all of stored delegates on every update event, and returns true if all of them returned true (the ones finished earlier are removed from internal collection). Higher-level behaviors can be implemented with an IEnumerable<Func<float, bool>> because it is easier to implement complex logic with generators.

The fact is that with this approach I could simulate thousands of objects with no CPU freezes due to synchronization. The only drawback is a constant FPS drop, but it was not something big. The next con is that it is not as handy in use as tasks.

from urho.