Time complexity of inserting `n` elements in a `java.util.PriorityQueue` with `initialCapacity=n`

Question

I have to construct a max-heap out of an array (called nums in the following code) and so I'm using java.util.PriorityQueue.

My code looks like this:

PriorityQueue<Integer> pq = new PriorityQueue<>(nums.length, (a, b) -> b - a);
for (int i = 0; i < nums.length; i++) {
    pq.offer(nums[i]);
}

I'm trying to find the time complexity (in terms of Big-O notation) of the above for loop.

I understand that PriorityQueue don't specify the details of the growth of underlying data structure. (And in worst-case it can be O(n) when expanding the internal-array and copying all the elements over the newly allocated space).

But I assume that when I specify the initialCapacity and don't add elements more than this initialCapacity, then the worst case time complexity of the above loop should be O(n) instead of O(nlog(n)). I understand from here that building time of heap is O(n) and nlog(n) is a loose upper bound.

Am I correct, or am I missing something?

I just want to understand that if I configure my PriorityQueue with initialCapacity of n and add n elements in that priority-queue, what will be the time complexity of this building-heap process?

PS: I already saw this, but answers for this question just claim things without explanation and may be they are not so Java specific.

I also see that java.util.PriorityQueue has a constructor that takes in a Collection. What will be the time complexity of this constructor? Shouldn't it be O(n)?

Answer 1

I understand that PriorityQueue don't specify the details of the growth of underlying data structure.

Let us be clear about this. The javadoc states that the policy for expanding the queue is unspecified.

(And in worst-case it can be O(n) when expanding the internal-array and copying all the elements over the newly allocated space).

The current policy (Java 11) is:

    // Double size if small; else grow by 50%
    int newCapacity = oldCapacity + ((oldCapacity < 64) ?
                                     (oldCapacity + 2) :
                                     (oldCapacity >> 1));

The amortized cost is O(1) per insertion for a "double" policy. For grow by 50% is is not as good. But is is way better than O(n).

It is safe to assume that they wouldn't unilaterally change this policy to something with substantially worse complexity, no matter what the current specification (technically) permits.

However, this is not germane to your question since you are using initialCapacity capacity, either explicitly, or when you populate the PriorityQueue from a collection.

I assume that when I specify the initialCapacity and don't add elements more than this `initialCapacity, then the worst case time complexity of the above loop should be O(n) instead of O(nlog(n)). I understand from here that building time of heap is O(n) and nlog(n) is a loose upper bound.

Am I correct, or am I missing something?

I think you are missing something.

Assuming that your input array is unsorted, building the heap ("heapification") and retrieving the elements in order is equivalent to sorting the elements into priority order. That is an O(nlogn) operation on average. While the heapification itself is O(n) (since the code uses sift down heapification), you have actually put off some of the sorting cost until later.

So unless you only intend to retrieve a non O(n) subset of the elements that you put into the queue, the overall answer is O(nlogn).

I just want to understand that if I configure my PriorityQueue with initialCapacity of n and add n elements in that priority-queue, what will be the time complexity of this building-heap process?

The overall complexity (adding and removing n elements) will be O(nlogn) for the reason stated above.

I also see that PriorityQueue has a constructor that takes in a Collection. What will be the time complexity of this constructor? Shouldn't it be O(n)?

If the collection is unsorted, then the elements must be heapified; see above. There is some special-case code to deal with a SortedCollection which skips the heapification step.

---

Notes:

1. You can confirm the details above by reading the source code for PriorityQueue. Google can find it for you.
2. The Wikipedia page on HeapSort talks about heapification
3. The proof that growing by doubling an array-based data structure is O(1) per insertion is given in good algorithms text books. The same analysis could be applied to growing by 50%.
4. Your lambda expression (a, b) -> b - a is not correct for ordering integers unless they are positive.