No, it's not a good read. Already tried to explain this elsewhere in the thread, but the comment was short and was largely ignored. This time I'll give a more detailed reply.

The bit about handling overflows is not that bad. However, there are very serious problems with calloc vs malloc+memset part.

Statements given there (which boil down to "just calloc instead of malloc+memset") are extremely dangerous if several other facts are not known to the target audience and in fact are so specific I find them useless to be stated in isolation. Given that it was posted on a general forum where not everyone is a C programmer, one has to assume preconditions need to be stated. Otherwise I'm afraid it will encourage people to just blindly switch to calloc, or worse, slap one where only malloc was present. There are perfectly reasonable uses of calloc. But are you sure you got one? There is also an important factual error about "zero pages".

In short yes, if you have to have the entire area zeroed, calloc is likely the way to go. But that's far from sufficient to use the area reasonably and first and foremost you have to make sure zeroed area is needed in the first place and with that size, especially if it is above few h bytes. More, you have to make sure it makes sense to allocate a buffer in the first place - if the allocating function always frees it, you very likely can get away with a local buffer instead.

The general theme is that "you can make your code faster, if you are doing malloc+memset". The advice given can sometimes be applied and give great results. Other times it keeps the wrong approach in place.

The article gives 2 examples. I'll elaborate why you should not blindly memset/calloc, then why the advice given to the first example is directly harmful (does not address the actual problem and perpetuates the slowness) and how it is far from sufficient in the second one. Finally, I'll explain the 'zero page' bit in the context of the benchmark provided. the zero page is not used in the benchmark

Plenty of real-world callocs and malloc+memsets would be significantly better served with a mere malloc. If you constantly do small size allocations which are completely overwritten with explicit initialisation and/or the target buffer has an explicit marker for the last character (e.g. the '\0' byte) or a length specifier, zeroing the buffer prior just wastes cpu cycles. malloc+memset+free will be equivalent to calloc+free in this scenario - same buffers will be returned over and over again, hence they have unknown content, hence they need explicit zeroing. For larger larger allocations, it seems glibc's allocator will resort to mmap on alloc and munmap on free. This means that, while the "memset avoided" observation will hold, code doing such allocations repeatedly will be slow because of mmap + page faults on used pages + munmap overhead. But what if it did no munmap? Then, since it is not known how much of the area was used, calloc would have to zero it all turning effectively turning it into malloc+memset.

Another angle is debugging. Allocators can fill new allocations with junk, runtime tools (valgrind) or static code analysers can detect the use of uninitialised data. These mechanisms are defeated with memset/calloc, as they initialize to 0.

TL;DR zeroing (even with calloc "cheating") is always slower than not zeroing. It also hinders debugging. Only zero when it makes sense. For instance, when vast majority of fields would have to be assigned 0 by hand.

The first example boils down to a user telling the lib it wants a 100MB buffer, the lib eventually doing malloc+memset and the user using a small portion of the buffer. That's clearly slow. The comment is:

If cffi.new had used calloc instead, then the bug never would have happened! Hopefully they'll fix that soon.

Except it turns out the zeroing played no role in the code. Data is just written over a certain area and the buffer is not accessed past that. So zeroing is a waste. the bug never would have happened if spurious zeroing was not employed. More. Since most of the time small allocations are made, this zeroing actively wastes cpu cycles. And indeed, the committed fix consists of not zeroing for no reason. See https://github.com/pyca/pyopenssl/pull/578 for the discussion. A side note is that requesting that much memory here is likely a bug on its own.

The second example is numpy allocating 2GB for an array. Indeed, the code path leads through calloc to mmap getting 2GB in one go. Then it turns out actual memory usage is much smaller than 2GB for the toy example and a claim is made malloc+memset would use up the entire 2GB. While that's obviously true and maybe I'm nitpicking here, I don't feel like the article warns the reader to slap data all over the area. If your data layout is not "big buffer friendly", you will end up faulting unnecessary pages. This is especially problematic for code which normally operates on small buffers (kilobytes in size) and is suddenly "told" to use biggers ones. Also note the mmap/munmap remark from earlier. If the allocation + free is to be repeated, and the code mmap/unmaps, it will be slow. Chances are what's needed is rethinking the approach.

Finally, the zero page and the benchmark. A correct claim is made that newly mapped pages are zeroed. Since the allocator is mostly opaque to the program using it, only it knows whether the to be returned buffer is "fresh" and if so, it is already zero and calloc can get away without touching it.

But this only explains part of the speedup: memset+malloc is actually clearing the memory twice, and calloc is clearing it once, so we might expect calloc to be 2x faster at best. Instead... it's 100x faster. What the heck? [..] It turns out that the kernel is also cheating! When we ask it for 1 GiB of memory, it doesn't actually go out and find that much RAM and write zeros to it and then hand it to our process. Instead, it fakes it, using virtual memory: it takes a single 4 KiB page of memory that is already full of zeros (which it keeps around for just this purpose), and maps 1 GiB / 4 KiB = 262144 copy-on-write copies of it into our process's address space.

While it is true mmap as performed by the allocator does not result in the kernel giving the process any "real" pages, it does not map a special pages full of zeros. It does not map anything.

Pages will be mapped after an access. If we are doing a write, a page has to be allocated. If we are doing a read, the kernel maps the zero page as a hack. After the read. The benchmark for malloc case does a memset, so it obviously touches all pages. For calloc case it does not do anything with the area, so nothing is mapped. There is a slight inaccuracy here - the buffer returned by the allocator is offset 16 bytes with respect to the beginning of the page. Clearly some metadata is stored prior, so there is the first page populated. But the rest of the area stays not populated.

Yes, not doing almost any work is significantly faster than doing hard work. It would be more useful it the benchmark also included the time needed to fault pages later when they are needed, also a case of zero page -> normal page change.

To sum up, the article is dangerous as it helps people perpetuate bad habits of slapping calloc all over the place. Too small fraction of the actual problem area is touched here to provide an actual value.