Re: profiling connection overhead

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Subject: Re: profiling connection overhead
Date: 2010-11-30 01:28:56
Message-ID: 201011300128.oAU1SuG07096@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-11-30 01:34:06 Re: profiling connection overhead
Previous Message Bruce Momjian 2010-11-30 01:13:26 Re: profiling connection overhead