Hacker News
points by fasterik 4 days ago | 0 comments
I think this is missing the forest for the trees. The potential savings of one extra size_t per allocation are miniscule compared to the overhead of using malloc() in the first place, with a potential syscall on every allocation. If you care about waste, you should ask for those pages from the OS directly, once at init, and use arenas.
[–] OskarS 4 days ago
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.

[–] 0c3ca83 4 days ago
There's no syscall on every allocation. With many allocators, the common case is popping a node off a linked list.
[–] fasterik 4 days ago
That's why I put the word "potential" in there. Every allocation potentially needs to go to the OS for more pages.
[–] 0c3ca83 4 days ago
And every memory access potentially enters the kernel via a page fault.
[–] cowlevel 3 days ago
Any given CPU instruction potentially isn't in cache.

And yet, they can't all not be in cache. As soon as the cache is accessed for one instruction, a bunch more are pulled in too.

Any given vector.push call could reallocate the vector, but it's amortized O(1).