@adamgfraser I might back with TMap[Int, A], TRef[Int], or similar, on the theory that if TMap is sufficiently optimized, it will permit less contention than a single Ref that contains the whole queue. /cc @mijicd

@jdegoes Based on the last benchmarks we have they're comparable, but we might have some "cut-offs" with TMap. However, in the end it's up to numbers, so I definitely propose a follow-up to benchmark the implementation.

If we do it with TMap[Int, A], TRef[Int] aren't we requiring the user to specify the priority in terms of an Int rather than just being able to provide an Ordering? Otherwise it seems like we are going to have to potentially reconstruct the keys (e.g. if the user adds an item with a priority between two existing values with successive integer priorities). In a way that would have negative performance implications.

Other thing we could potentially do here is implement our heap structure like a pairing heap instead of using SortedMap for this.

If we do it with TMap[Int, A], TRef[Int] aren't we requiring the user to specify the priority in terms of an Int rather than just being able to provide an Ordering? Otherwise it seems like we are going to have to potentially reconstruct the keys (e.g. if the user adds an item with a priority between two existing values with successive integer priorities). In a way that would have negative performance implications.

Other thing we could potentially do here is implement our heap structure like a pairing heap instead of using SortedMap for this.

I find using Int too limiting for priority as I have timestamps in mind (like epoch) and those are ultimately Long and assume values that could not be accommodated by Ints. I think time priority is fairly common usage.

@adamgfraser For this PR, I wouldn't change from TRef, we can always use TMap later, and yes, we can use TMap for any key that is orderable.

@jdegoes Okay, yeah I realized we can just do it as TMap and bubble up to maintain the invariant with just an ordering. Let me clean this up and then we can do that.

Okay, I think I addressed everyone's comments. If people are good with this let's merge and then I can optimize the internal representation in a follow up PR.

Initial version with TMap. This moves to a single type parameter which I think is definitely an improvement. I do worry about the number of STM operations we are using in the implementation. With the TMap we are potentially getting more parallelism because different fibers could be modifying different parts of the data structure but we are making non-local changes to maintain the heap structure and having to go through multiple STM operations instead of just being able to modify a single underlying data structure so I am not sure we come out ahead.

@adamgfraser I agree the overhead of this will be extremely high, and a TRef with sorted set is likely to be much, much faster. But it could be done in followup.