[Haskell-cafe] Performance of functional priority queues

wren ng thornton wren at freegeek.org
Wed Jun 17 02:03:33 EDT 2009


Richard O'Keefe wrote:
> There's a current thread in the Erlang mailing list about
> priority queues.  I'm aware of, for example, the Brodal/Okasaki
> paper and the David King paper. I'm also aware of James Cook's
> priority queue package in Hackage, have my own copy of Okasaki's
> book, and have just spent an hour searching the web.
> 
> One of the correspondents in that thread claims that it is
> provably impossible to have an efficient priority queue implementation
> without mutability.  I think he's cuckoo.  But I'd like to have some
> numbers to back me up.

Sounds cuckoo to me until I see a proof otherwise. I've seen a few proof 
sketches indicating that immutable approaches can always be no worse 
than a O(log n) multiple of imperative ones (by simulating main memory 
with your O(log n) map of choice). Between this and the provable 
asymptotic optimality of skewed binomial heap prioqueues, the argument 
sounds untenable.

Though it really comes down to what they mean by "efficient". Asymptotic 
complexity is the name of the game for most folks in algorithms and 
datastructures, but that seems not to be what they're after. Shrinking 
the constant factors is frequently a game that can go on forever, or 
rather can seldom be proved not to, so the claim seems unlikely to be 
meaningful in this arena either (you'd have to prove you've found the 
smallest possible constant factor for any immutable approach, and then 
find a smaller one for some mutable approach). Also proofs about 
constant factors beyond basic thresholds aren't useful in practice due 
to hardware barriers like cache size and disk access times.

There's also the difference between compilers that are designed to 
optimize immutable patterns, vs ones which aren't. For example, in 
certain circumstances and with suitable annotations Clean will take the 
immutable approach and convert it into a mutable variant for you, thus 
saving on allocation/collection/cache-miss overheads while maintaining 
the spirit of immutability. Is compiled code like this considered 
"mutable" or "immutable"? It all depends on the spirit of the question.


> Can anyone point me to some actual benchmark results comparing
> priority queue performance *with* mutation and priority queue
> performance *without* mutation, in the same functional or
> mostly-functional language?

I'm always curious to see datastructure benchmarks though :)

-- 
Live well,
~wren


More information about the Haskell-Cafe mailing list