This is a completely ridiculous article. The whole concept is flawed. New/delete like this are for smallish general purpose allocation, for example of objects,

This is a completely ridiculous article. The whole concept is flawed. New/delete like this are for smallish general purpose allocation, for example of objects, where we want to keep the code at a fairly high level in C++ and not think about low-level concepts like "bytes" or allocation mechanics. Or performance. Conversely, an app written in C++ that needs huge swaths memory for manipulating raw bytes and needs high-performance would not likely use new char[] or calloc/malloc directly at all. It would directly interface with the OS via mmap or indirectly via some domain relevant library, for example, OpenCV. We might even still exclusively use the C++ language to write the low-level portions of the code, but if you need to interface with the OS in specific controlled ways or write performance oriented code, you are not going to do it using only high-level C++ operations. You are going to call exactly what you need to interface with the system directly. If you want mmap(), you'd just call mmap() from C++. If you want sbrk(), you'd call sbrk(). If you don't like the system new/delete and malloc/free, you could use something like dlmalloc and and even remap new/delete to it, or to some custom slab allocator. Secondly, as pointed out by others, the author isn't benchmarking C++. He's benchmarking glibc malloc and the Linux mmap. We'd expect a C program using malloc/calloc to have exactly the same timings. Thirdly, fallacious reasoning about initialization. If your app needs to allocate (for some ??? reason) 32 GB of memory, you would NOT automatically zero it first, unless you actually needed it to be zero, or you wanted your app to waste a bunch of time. Unnecessary zeroing huge arrays is not required for good security. We're mostly benchmarking memset here, not even malloc/mmap. So it's completely apples/oranges to compare mmap benchmark with a zerofill benchmark. I almost expect a follow-up article that points out accessing x[i] is much faster when x is a raw array of integers than when x is a std::map of strings. Now read the footnotes. The author is misunderstanding what "idomatic C++" means. RAII is the best answer I can come up with for idiomatic - C++ doesn't have a built-in guard concept so we creatively mis-use constructors and destructors to get a similar result. Footnote 2 proves the author knows bupkis about how C++ or any part of the system actually works. He's semi-admitting as much. I'd hope for much better from a CS professor. Stick to benchmarking this: for(i=0; i<1E9; ++i);