The background
According to Wikipedia and other sources I’ve found, building a binary heap of n elements by starting with an empty binary heap and inserting the n elements into it is O(n log n), since binary heap insertion is O(log n) and you’re doing it n times. Let’s call this the insertion algorithm.
It also presents an alternate approach in which you sink/trickle down/percolate down/cascade down/heapify down/bubble down the first/top half of the elements, starting with the middle element and ending with the first element, and that this is O(n), a much better complexity. The proof of this complexity rests on the insight that the sink complexity for each element depends on its height in the binary heap: if it’s near the bottom, it will be small, maybe zero; if it’s near the top, it can be large, maybe log n. The point is that the complexity isn’t log n for every element sunk in this process, so the overall complexity is much less than O(n log n), and is in fact O(n). Let’s call this the sink algorithm.
The question
Why isn’t the complexity for the insertion algorithm the same as that of the sink algorithm, for the same reasons?
Consider the actual work done for the first few elements in the insertion algorithm. The cost of the first insertion isn’t log n, it’s zero, because the binary heap is empty! The cost of the second insertion is at worst one swap, and the cost of the fourth is at worst two swaps, and so on. The actual complexity of inserting an element depends on the current depth of the binary heap, so the complexity for most insertions is less than O(log n). The insertion cost doesn’t even technically reach O(log n) until after all n elements have been inserted [it’s O(log (n – 1)) for the last element]!
These savings sound just like the savings gotten by the sink algorithm, so why aren’t they counted the same for both algorithms?
The intuition is that the sink algorithm moves only a few things (those in the small layers at the top of the heap/tree) distance log(n), while the insertion algorithm moves many things (those in the big layers at the bottom of the heap) distance log(n).
The intuition for why the sink algorithm can get away with this that the insertion algorithm is also meeting an additional (nice) requirement: if we stop the insertion at any point, the partially formed heap has to be (and is) a valid heap. For the sink algorithm, all we get is a weird malformed bottom portion of a heap. Sort of like a pine tree with the top cut off.
Also, summations and blah blah. It’s best to think asymptotically about what happens when inserting, say, the last half of the elements of an arbitrarily large set of size n.