On the bright side, lots of people will be saved from reading bad prose like "Malloc (libc) is the worst memory allocation API to use" and "Programs should avoid, if possible, allocating/deallocating memory too often". (By definition, "too often" means it can possibly be avoided, and usually that it can practically be avoided.)
The first one was offered with no explanation and no claimed better alternative. malloc() is probably the simplest interface for generic runtime allocation, and simplicity has a lot in its favor. malloc() does not provide type safety, is susceptible to external fragmentation, and makes it harder to meet the performance goals outlined in the rest of the blog post. So malloc() reflects trade-offs, but saying that the standard API "is the worst memory allocation API to use" should be supported, even if briefly, instead of simply asserted: meeting the goals I listed inflicts other drawbacks, like needing to create and manage separate heaps.
I thought my explanation for the second one was already clear: "Programs should avoid, if possible, [doing X] too often" is a truism because "too often" implies that some reduction is possible. One should leave out the ", if possible," -- although deciding what is "too often" can be challenging and sometimes a matter of taste. (Is reducing allocation frequency by 5% worth doubling the CPU usage or memory usage or code complexity? Maybe in some cases, but often not.)
reply