malloc_size can be useful for cases where you’re allocating a buffer which is dynamically changing size over time, and you want to just use the entire buffer you get rather than leaving a bunch slack. For instance, think of std::vector storage, you would prefer that both the STL and underlying malloc library don’t each have a bunch of unused padding in there. Better would be to use something like malloc_good_size(), since the library can usually answer that question directly without any heap references, but that’s also non-standard.
Apple’s implementation stores the length in a side bitmap which covers a large chunk of memory. Some other implementations store the info in a prefix of the allocated space, which will generally be very fast since it’s likely to share cache lines with the allocated data.
A S Gowri Sankarsays:
If the issue with the search algorithm efficiency is in the Kernel, I really hope it’s in the Darwin piece of it, not the BSD piece
malloc_size can be useful for cases where you’re allocating a buffer which is dynamically changing size over time, and you want to just use the entire buffer you get rather than leaving a bunch slack. For instance, think of std::vector storage, you would prefer that both the STL and underlying malloc library don’t each have a bunch of unused padding in there. Better would be to use something like malloc_good_size(), since the library can usually answer that question directly without any heap references, but that’s also non-standard.
Apple’s implementation stores the length in a side bitmap which covers a large chunk of memory. Some other implementations store the info in a prefix of the allocated space, which will generally be very fast since it’s likely to share cache lines with the allocated data.
If the issue with the search algorithm efficiency is in the Kernel, I really hope it’s in the Darwin piece of it, not the BSD piece