Hacker News
points by OskarS 4 days ago | 0 comments
If you think you can convince the entire computer industry to stop using malloc(), I wish you the best of luck. In actuality, your computer likely calls malloc() somewhere thousands of times per second in low use, probably millions of times during intensive use. Wouldn't it be nice if all those calls were just a bit less resource intensive?
[–] fasterik 4 days ago
I'm curious, what do you expect the performance improvement to be, in terms of CPU cycles per allocation? malloc() costs on the order of 10,000 cycles on the slow path.
[–] OskarS 4 days ago
I don't know what the exact impact would be, but it's certainly not zero, and multiplied by every malloc, it adds up. My point is mostly that the API for malloc()/free() is designed in such a way to both limit the kind of implementations you can make for it, and make most implementations a tiny bit slower than they need to be.

BTW, when malloc() takes 10,000 cycles, you've either hit some weird edge case in an allocator or (much more likely) malloc() has run out pages it can use to hand over to the application and has to ask the kernel for more memory. I measured malloc() for a recent change in one of our products, and in my test the median time was less than 100ns. malloc() is usually very fast. But with a better API, it could be faster. Multiplied by every memory allocation on every computer in the world (more or less) for the last half-century, it's becomes a very big number.