Re: profiling connection overhead

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

On Monday 29 November 2010 18:34:02 Robert Haas wrote:
> On Mon, Nov 29, 2010 at 12:24 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Hm. A quick test shows that its quite a bit faster if you allocate memory
> > with:
> > size_t s = 512*1024*1024;
> > char *bss = mmap(0, s, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_POPULATE|
> > MAP_ANONYMOUS, -1, 0);
>
> Numbers?
malloc alloc: 43
malloc memset1: 438763
malloc memset2: 98764
total: 537570

mmap alloc: 296065
mmap memset1: 99203
mmap memset2: 100608
total: 495876

But you don't actually need the memset1 in the mmap case as MAP_ANONYMOUS
memory is already zeroed. We could actually use that knowledge even without
MAP_POPULATE if we somehow keep track whether an allocated memory region is
still zeroed.

Taking that into account its:

malloc alloc: 47
malloc memset1: 437819
malloc memset2: 98317
total: 536183
mmap alloc: 292904
mmap memset1: 1
mmap memset2: 99284
total: 392189

I am somewhat reluctant to believe thats the way to go.

Andres

Attachment Content-Type Size
zero.c text/x-csrc 1.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2010-11-29 17:50:08 Re: profiling connection overhead
Previous Message Robert Haas 2010-11-29 17:36:37 Re: PROPOSAL of xmlvalidate