Closed dougmill closed 6 years ago
I'll leave this open for a while, but I don't think there's going to be a good solution. A priority queue that uses structures (which will be slower for .Contains()
, but might be faster for other operations) might suit your needs better.
Turns out for this project I can use wrapper nodes with minimal performance cost because I almost never need to find a wrapper node given the node it wraps. That cuts out the ubiquitous dictionary lookups that I think are the main performance reduction in the simple queue.
I've been finding in my project that I need multiple priority queues for different purposes, and some of the same objects need to go in each queue. This obviously requires multiple index values, and potentially multiple priority values, but
FastQueuePriorityNode
only allows for one of each.At first I handled this by making a renamed copy of
FastPriorityQueue
and its node class, converting the node classes to interfaces, implementing both interfaces on the queued object, and using the copy for the second queue. But now "two queues" has expanded to "arbitrarily many queues" and that won't work any more.SimplePriorityQueue
can handle this by wrapping the object in a per-queue node wrapper, but I'd rather not accept the performance cost for that.I'm working on a solution for my project, but I'm not sure it won't have any project-specific details and I expect there are plenty of other people who would find multi-queue support useful.