max-heap | Max Heap is a data structure

(V8 developer here.)

1. Is it normal that peak_malloced_memory can exceed total_heap_size?

Malloced memory is unrelated to the heap, so yes, when the heap is tiny then malloced memory (which typically also isn't a lot) may well exceed it, maybe only briefly. Note that peak malloced memory (53 MiB in your screenshot) is not current malloced memory (24 KiB in your screenshot); it's the largest amount that was used at any point in the past, but has since been freed (and is hence not a leak, and won't cause an OOM over time).

Not being part of the heap, malloced memory isn't affected by --max-heap-size or --max-old-space-size, nor by manual gc() calls.

1. Why could this occur only when using JS's optional chaining?

That makes no sense, and I bet that something else is going on.

1. Are there any other, more correct solutions to this problem other than forcing full GC all the time?

I'm not sure what "this problem" is. A brief peak of malloced memory (which is freed again soon) should be fine. Your question title mentions a "leak", but I don't see any evidence of a leak. Your question also mentions OOM, but the graph doesn't show anything related (less than 10 MiB current memory consumption at the end of the plotted time window, with 2GB physical memory), so I'm not sure what to make of that.

Manually forcing GC runs is certainly not a good idea. The fact that it even affects (non-GC'ed!) malloced memory at all is surprising, but may have a perfectly mundane explanation. For example (and I'm wildly speculating here, since you haven't provided a repro case or other more specific data), it could be that the short-term peak is caused by an optimized compilation, and with the forced GC runs you're destroying so much type feedback that the optimized compilation never happens.

Happy to take a closer look if you provide more data, such as a repro case. If the only "problem" you see is that peak_malloced_memory is larger than the heap size, then the solution is simply not to worry about it.

There are two problems:

• After b has been set to False the swap is still executed before exiting the loop. Execution should break out of the loop with break. This also makes the boolean b unnecessary.

• The condition int(l/2) < 2 should be int(l/2) < 1, as really the parent at index 1 should be compared with.

Other remarks:

• Make use of the integer division operator instead of flooring the floating point division.

• When you slice until the end, using 1:len(arryhp), you can omit the part after the colon: 1:.

• It is not nice that the returned list is not the mutated list that was given as argument. Either the input list should not be mutated, or the list that is returned is the mutated input list. The latter can be done by popping the first value out of the list with .pop(0).

Here is the code with those changes:

Build: Use median-of-medians to find the initial median in O(n), use it to partition the values in half. The half with the smaller values goes into a max-heap, the half with the larger values goes into a min-heap, build each in time O(n). We'll keep the two heaps equally large or differing by at most one element.

Median: The root of the bigger heap, or the mean of the two roots if the heaps have equal size.

Insert: Insert into the bigger heap, then pop its root and insert it into the smaller heap.

The thing is that you can only rely on MAX_HEAPIFY to do its job right, when the subtree that is rooted at i obeys the heap property everywhere except possibly for the root value (at i) itself, which may need to sift down. The job of MAX_HEAPIFY is only to move the value of the root to its right position. It cannot fix any other violations of the heap property. If however, it is guaranteed that the rest of the tree below i is obeying the heap property, then you can be sure that the subtree at i will be a heap after MAX_HEAPIFY has run.

So if you would start with top node, then who knows what you will get... the rest of the tree is not expected to obey the heap property, so MAX_HEAPIFY will not (necessarily) deliver a heap. And it doesn't help to continue the work in a top-down fashion.

If we take the example tree and perform the forward loop alternative, then we start with a call of MAX_HEAPIFY(1) on this tree:

In a zero-based indexed array, the root is at index 0. The children of the root are at index 1 and 2. In general the children of index 𝑖 are at indices 2𝑖+1 and 2𝑖+2.

So for a node to have children, we must have that 2𝑖+1 (i.e. the left child) is still within the range of the array, i.e. 2𝑖+1 < 𝑛, where 𝑛 is the size of the array (i.e. the last index is at 𝑛-1).

Which is the index of the first leaf? That would be the least value of 𝑖 for which 2𝑖+1 < 𝑛 is not true, i.e. when 2𝑖+1 ≥ 𝑛. From that we can derive that:

• All indices that represent leaves are grouped together. They are all at the 𝑖, for which 2𝑖+1 ≥ 𝑛

• The least index of a leaf is at index 𝑖 = _⌊𝑛/2_⌋.

If you are working with a one-based indexed array (as is common in pseudo code), then you can adapt the above reasoning to derive that the first leaf is at index 𝑖 = _⌊𝑛/2_⌋+1.

So the answer you quote is assuming a 1-based indexed array, and then it is correct to say that the first leaf is positioned at _⌊𝑛/2_⌋+1, and any leaf is at a position _⌊𝑛/2_⌋+𝑘, where 𝑘≥1.

Let's say I add one more node in this half-filled level. Practically, I fail to see how this somehow reduces the number of steps/comparisons that occur and is no longer the worst case . Even though I have added one more node, all the comparisons occur only on the left subtree and has nothing to do with the right subtree.

It is correct that this does not reduce the number of steps. However, when we speak of time complexity, we look for a relation between the number of steps and 𝑛. If were to only look at the number of steps, we would only conclude that the worst case happens when the tree is infinitely large. Although that is a really bad case (the worst), that is not what the book means with "worst case" here. It is not just the number of steps that interests us, it is how that number relates to 𝑛.

We can argue about the terminology here, because usually "worst case" is not about something that depends on 𝑛, but about variations that can exist for a given 𝑛. For instance, when discussing worst case scenarios for a sorting algorithm, the worst and best cases are dependent on how the input data is organised (already sorted, reversed, ...etc). Here "worst case" is used for the shape of the (bottom layer of the) tree, which is directly inferred by the value of 𝑛. Once you have 𝑛, there is no variation possible there.

However, for the recurrence relation, we must find the formula -- in terms of 𝑛 -- that gives an upper limit for the number of children in the left subtree, with the constraint that we want this formula to use simple arithmetic (for example: no flooring).

Here is a graph where the blue bars represent the value of 𝑛, and the orange bars represent the number of nodes in the left subtree.

The recurrence relation is based on the idea that the greatest subtree of both subtrees is the left subtree, so it represents the worst case. That subtree has a number of nodes that is somewhere between (𝑛-1)/2 and 2𝑛/3. The ratio between the number of nodes in the left subtree and the total number of nodes is maximised when the left subtree is full, and the right subtree has a lesser height.

Here is the same data represented as a ratio:

You can see where these maxima occur: when 𝑛 is 2, 5, 11, 23, ... the ratio between the number of nodes in the left subtree and 𝑛 approaches 40%. This 40% represents the upper limit for the ratio, and is a safe "catch-all" for all values of 𝑛.

We need this ratio in the recurrence relation: that 40% can be rephrased: the number of nodes in the subtree has an upper bound of 2𝑛/3. And so the recurrence relation is

              𝑇(𝑛) = 𝑇(2𝑛/3) + O(1)

No, the algorithm you propose will not work generally. It wrongly assumes that the leaves of the max heap cannot have a value that is greater than the median. This is not true. Here is a counter example:

input: [7, 6, 3, 5, 4, 2, 1]

1. build max-heap (h) from given array

The input happens to already be structured as a max-heap. It is:

Okay, prepare for a ride.

1. First I found a bug
2. Next, I fully reviewed, refactored and simplified the code
3. When the dust settled, I noticed a behaviour change that looked like a potential logic error in the code

Like I commented at the question, the code complexity is high due to over-reliance on raw pointers without clear semantics.

While I was reviewing and refactoring the code, I found that this has, indeed, lead to a bug:

In response to "they do the same thing" comment. Not quite. If getline fails the string is left untouched (in this case).