When I was younger and still stuck thinking in terms of concrete current implementations more than abstract semantics and their best possible implementations, I kept wanting to bypass the standard library, especially in low-level languages like C, because the standard library had code paths I didn't need.
If I knew I didn't need my newly allocated memory to start zeroed out, I disliked calling calloc, because a naive implementation of calloc implies extra work, and most implementations would imply extra work at least some of the time. Because I failed to conceive of the OS and hardware having extremely efficient code and circuitry for giving us zeroed out memory pages, and I failed to conceive of optimizing compilers generating code which doesn't bother zeroing out that memory if you truly never read those bytes before writing them.
If I just wanted one memory allocation for the lifetime of the program, I disliked calling malloc at all, because most malloc implementations have a complex memory allocator which is only more optimal for larger and churnier memory usage. I wanted to call the rawest, most direct memory allocation operation - for example, on modern Linux that's an mmap system call asking for an anonymous page (or for a mapping of /dev/zero, although I later learned of sloppy/overbroad SELinux policies in production, f.e. on some Android devices, which reject opening or mapping /dev/zero). Or I wanted to just manually try to grow the stack (and have raw feedback from the kernel if I didn't have enough). Because I was stuck thinking about what the concrete implementations I had on hand would do. Instead, I should've been imagining the optimizing compiler which can look at a simple "malloc", and at everything else in the code, and at any optimization preferences and other information passed in when invoking the compiler, and just compile that malloc as a raw memory system call, or as a stack allocation, if that's actually the best thing to do in that situation.
Painstakingly chipping away at this has been one of the most liberating and healing things for me as a software developer. This is why I eventually realized that we should "code for the optimizer" rather than optimizing by hand in almost every situation. But it took the overwhelming accumulation of examples of actual real-world situations where automatic optimizations beat manual fiddling, or did just as well, and where the manual fiddling was actively counter-productive.
I wish they taught this in schools or something. Just one class, one semester, which is mostly just a showcase of "here's some code. here's how it could be inefficient. how might we optimize this? yeah, yeah, cool, cool... good ideas class. Now here's what a modern compiler can do if you just give it the simple code that doesn't try to optimize. Notice how it did everything you thought of, plus things you didn't. And oh look, if we change the optimization tuning from execution speed to memory usage for example, the compiler can optimize the simple code totally differently, but our hand-optimized code is stuck using more memory, because the compiler can no longer discern the relevant intent and invariants in this code - and neither could a human, without extensive comments and context".
I know lots of developers just don't care, but it would go a long way towards either unblocking or constructively directing the type of developer who can be very productive but would otherwise spend too much time prematurely or needlessly optimizing in the wrong places.













