(One problem is that we can get lots of “change key” notifications in a row as an image incrementally downloads and decodes. This is a lot of useless churn. I suppose I could combine both push/pop and dirty bits, but as I said, it’s not a hotspot at all.)

Let’s ignore esoteric heaps and concentrate on STL heaps. I don’t understand the use case well enough, but many O(log n) may beat a few O(n) even for small n. Probably best to benchmark push_heap and pop_heap instead of guessing. O(log n) may be faster than you think!

The second problem was that Fibonacci heap, as I saw it, didn’t support increase_key in an O(1) way. And doing even O(log(n)) work on each of these elements (small n at any one time, but large churn) was, in my mind, a non-starter.

And, when it came to choosing between implementing a heap on my own and just trying lazy updating, _of course_ I chose the latter.

Whenever I removed an element, though, through Cancel() or other reasons, or – and this is much more important – an element’s weight got changed, either because it got another cache hit, or we loaded more information from the network, we had to heapify all over again. Heapification is O(N).

Fibonacci heaps have an O(1) |decrease key| operation, but unfortunately that doesn’t map directly to the changes that happen while images are loading and being used.

Are you sure? push_heap and pop_heap should be O(log n):

http://www.cppreference.com/wiki/stl/algorithm/push_heap