Quote:
Originally Posted by
DreamWarrior
Please bring in 2 GB worth of pages kernel; I'll wait, lol.
It's not much of a wait. On my 5 yr old laptop, memset()-ing 2 GB takes a fraction of a second. I didn't time the memset() itself, but it took less than one quarter of a second to complete a fork-exec-main-malloc-memset-exit sequence, which determines the upper bound with plenty of padding.
Even so, memset() is largely irrelevant in this scenario. For a single, unusually large allocation, you're practically guaranteed that there won't be a suitable chunk already available within the allocator's store. In that case, the requested pages will need to be allocated with sbrk or mmap and those pages will be zeroed by the kernel regardless. I repeat, whether you call malloc or calloc, in this scenario, you will be getting zeroed memory. And, with calloc(), you get complimentary overflow checking. WOOHOO!
I looked over the glibc, FreeBSD, and OpenBSD calloc() implementations and they never re-zero memory that's freshly delivered by sbrk() or mmap(). Should anyone care to have a look for themselves, for your convenience:
glibc malloc.c
FreeBSD malloc.c
OpenBSD malloc.c
Furthermore, it's quite possible that alll of those zeroed pages are backed by a single zeroed page that the kernel keeps around specifically for such situations. In that case, a real page won't be mapped until something is written.
A last point. If you really, really, really truly care about squeezing every last ounce of performance from the allocators (some folks do even when it's unwarranted), then don't use malloc and friends. They're designed to be general purpose routines and the tradeoffs involved beget complexity. A stupid, simple, single-purpose, tailor-made solution may be called for (although this is very seldom the case).
Regards,
Alister