Tom Lane wrote:
> BTW, this might be premature to mention pending some tests about mapping
> versus zeroing overhead, but it strikes me that there's more than one
> way to skin a cat. I still think the idea of statically allocated space
> sucks. But what if we rearranged things so that palloc0 doesn't consist
> of palloc-then-memset, but rather push the zeroing responsibility down
> into the allocator? In particular, I'm imagining that palloc0 with a
> sufficiently large space request --- more than a couple pages --- could
> somehow arrange to get space that's guaranteed zero already. And if the
> request isn't large, zeroing it isn't where our problem is anyhow.
> The most portable way to do that would be to use calloc insted of malloc,
> and hope that libc is smart enough to provide freshly-mapped space.
> It would be good to look and see whether glibc actually does so,
> of course. If not we might end up having to mess with sbrk for
> ourselves, and I'm not sure how pleasantly that interacts with malloc.
Yes, I was going to suggest trying calloc(), either because we can get
already-zeroed sbrk() memory, or because libc uses assembly language for
zeroing memory, as some good libc's do. I know most kernels also use
assembly for zeroing memory.
> Another question that would be worth asking here is whether the
> hand-baked MemSet macro still outruns memset on modern architectures.
> I think it's been quite a few years since that was last tested.
Yes, MemSet was found to be faster than calling a C function, but new
testing is certainly warranted.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
