If you are concerned about performance at that level you likely shouldn't be allocating and de-allocating memory all the time, as that is slow even without zeroing. You should use a memory pool to allow re-using your allocated memory.

> You should use a memory pool to allow re-using your allocated memory

Soon: programs implement their own allocators and memory pools and stop using the libc malloc, and thus stop benefiting from all the safety valves added to the libc malloc (including TFA), all because of the rumor that the libc malloc is slow (when it likely isn't).

Actually, that happened a couple decades ago.

Sometimes a well placed "placement new" is enough. Memory pools are also nice, but at least for my work we ditched them again once the Windows allocator became faster.

(I can count the times I did either of these on one hand, but of course this depends a lot on the code your working on).

seems like something that could be handled at the memory/controller level instead of wasting CPU cycles writing 0's.

It can be faster or slower, it's a wash at worst if you're calloc()ing later anyway, and it helps swap (or memory compression on swap-less iOS).