Comments on: I guess PriorityBlockingDeque wasn’t high on the priority list..

By: Avah

Avah — Fri, 05 Oct 2007 10:58:14 +0000

Heh, and I read them carefully but misunderstand what they mean. Well, anyway, that’s sorted out. Thanks for the input!

By: BrightByte

BrightByte — Fri, 05 Oct 2007 10:48:31 +0000

Hah, no it doesn’t confirm what I said. I should have read the docs carefully. Collections.sort is smarter than i thought – while a naive binary search on a LinkedList would be O(n * log(n)), Collections.sort does it in n steps with only log(n) comparisons, as opposed to n steps and n comparisons for the linear scan i suggested. I guess this is made possible by the fact that ListIterator can move both ways.

Another mistake I made is: ListIterator does haven an insert method (add). Sorry.

So, as it turns out, your LinkedList/Collections.sort based implementation seems to be optimal (or at least, slightly better than what I suggested), and I should read the documentation more closely

Thanks for this great blog, btw.

By: Avah

Avah — Fri, 05 Oct 2007 09:15:20 +0000

What you said brought up a memory and after careful checking I remembered why I didn't use ArrayList in the first place (as it's obviously the more efficient one) - it doesn't have pollFirst and pollLast functionality at all, as it doesn't implement the Deque interface, unlike LinkedList. However, a Deque implementation using a ring-array is definitely possible, and I'm sure there's a ring-array implementation somewhere out there to be used instead of re-writing it. However, as to what you said, take a look at the Collections.sort documentation:

This method runs in log(n) time for a "random access" list (which provides near-constant-time positional access). If the specified list does not implement the RandomAccess interface and is large, this method will do an iterator-based binary search that performs O(n) link traversals and O(log n) element comparisons.

If I understand this correctly, this verifies what you said.

By: BrightByte

BrightByte — Fri, 05 Oct 2007 08:41:00 +0000

Using an ArrayList would give you O(log(n)) complexity for add, but means O(n) complexity for removing the head of the queue (at least I think so – again, I have not looked at how ArrayList is implemented, exactly).

So, assuming an equal total number of add and remove/poll operations, the options appear to be: Use a LinkedList, with O(n) for add and O(1) for remove, giving you an amortized complexity of O(n), or using an ArrayList with O(log(n)) for add and O(n) for remove/poll, again giving you an amortized complexity of O(n), but with more overhead in practice (because you need n+log(n) steps and, as you mentioned, possibly for growing the array).

It would be interesting to run a benchmark to see which one is actually better for a “practical” size of the queue and number of add/remove operations.

By: Avah

Avah — Thu, 04 Oct 2007 19:11:33 +0000

You’re right, however, I could always change it to ArrayList and get it over with – receive the log(n) efficiency on one hand but might stumble upon bad efficiency during add() methods that exceed the size.

For that case, I could probably use the capacity to create the list at the right size right from the start (unless it’s Integer.MAX_VALUE, of course).

By: BrightByte

BrightByte — Thu, 04 Oct 2007 19:02:38 +0000

I havn’t looks at how LinkedList and Collection.sort are implemented in detail, but doing a binary search on a linked list seems to be a bad idea to me. Accessing index i takes i steps on a linked list, so a binary search would be in O(n * log(n)). Simple linear scanning would be faster (O(n)). It’s kind of sad that ListIterator doesn’t have an insert method – that would avoid the issue that you have to scan twice: once iterating over the list to find the right place to insert your element, then again to actually insert it, using add(int, Object).

Anyway, by not doing a binary search but simply scanning for the place to insert the new item, i believe you can bring the complexity of add from O(n*log(n)) down to O(n). Still not great, but better…

By: Avah

Avah — Wed, 26 Sep 2007 21:27:49 +0000

You’re right. I’ve changed it and checked it in.

By: Hanson Char

Hanson Char — Mon, 24 Sep 2007 09:47:56 +0000

>with a Collections.sort call when adding elements

There is no need to sort when adding elements. Sorting is necessary only when the list is initially constructed. Subsequently adding elements only requires a binary search + insert. That will yield ln(n) instead of n*ln(n) time.

By: Avah

Avah — Wed, 19 Sep 2007 04:56:26 +0000

I’ve created a test for it, and sure enough it fails with duplicate values; I’ve re-implemented it, this time using a LinkedList with a Collections.sort call when adding elements, and now it accepts duplicates.

I’ve checked it in so it should be available now.

By: Hanson Char

Hanson Char — Wed, 19 Sep 2007 01:53:11 +0000

>implementing PriorityDeque using a List and
>Collections methods would probably prove to be
>better conceptually, if not in performance, since it
>will permit duplicate values, something that
>NavigableSet does not.
>What do you think?

That’s basically what I was trying to suggest