Large queues allocated

In ContinuationProcessor<T>, you allocate two arrays of size 500,000. This uses about 30 MB of memory for each type of IAwaitInstruction used (WaitForFrames, WaitForSeconds, etc), regardless of how few Continuations you actually use.

You could instead start the queue size small (like 16) and dynamically resize the arrays. For example:

public void Add(T cont)
{
	if (futureCount == futureQueue.Length)
	{
		int newLength = futureQueue.Length * 3 / 2;
		Array.Resize(ref futureQueue, newLength);
		Array.Resize(ref currentQueue, newLength);
	}

	// rest of method...
}

[muckSponge]

A priority queue is only applicable if you can assign each item a priority. That works for WaitForFrames or WaitForSeconds, but won’t work with WaitWhile.

I was thinking something like…

interface IPriorityAwaitInstruction<T> where T : IComparable<T>
{
	public T Priority { get; }
}

… for instructions which could be assigned a priority (and an accompanying priority queue processor), and keeping IAwaitInstruction for others but that’s getting into over-engineered territory. I originally thought returning an int would be fine but that’s not going to play too nicely with something like WaitForSeconds.

I’m going to close this issue because we’ve fixed it but thanks for your feedback and discussion on the other points 😃

[muckSponge]

It throws an exception for me too. I’ve added a slightly more complex resize check in Add to avoid this. Basically, it considers how many awaiters are left in the current queue. Worst case all of them will need to be re-added so it resizes to ensure that if that is the case, there will be enough capacity for them. Not sure about whether to resize to 1.5x the largest potential queue size or 1.5x the current. I’ve done the latter but now I’m leaning toward the former (probably better to resize less frequently if it can be helped).

I went to all this trouble instead of calling Add inside Process because by their nature, these awaiters are likely to be evaluated over many frames. You’ll typically have more awaiters active than awaiters being added in any one frame. As such, I wanted to keep the hot path in Process as lean as possible. This meant doing a bit more work in Add, which I hope is a good trade-off. I haven’t benchmarked it though, I’ve found it really difficult to get reliable figures in the past.

I was thinking, for the threading issue where a background thread could call Add and manipulate the futureCount, instead of locking I could add a check to determine if it is called from in Unity’s SynchronizationContext and if not, just await the UnitySynchronizationContext. A simple sync context comparison should be faster than a lock that’s rarely needed, and it means I don’t need to lock in Process.