From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, 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-29 17:50:12 |
Message-ID: | 189.1291053012@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I guess the word "run" is misleading (I wrote the program in 5
> minutes); it's just zeroing the same chunk twice and measuring the
> times. The difference is presumably the page fault overhead, which
> implies that faulting is two-thirds of the overhead on MacOS X and
> three-quarters of the overhead on Linux.
Ah, cute solution to the measurement problem. I replicated the
experiment just as a cross-check:
Fedora 13 on x86_64 (recent Nehalem):
first run: 346767
second run: 103143
Darwin on x86_64 (not-so-recent Penryn):
first run: 341289
second run: 64535
HPUX on HPPA:
first run: 2191136
second run: 1199879
(On the last two machines I had to cut the array size to 256MB to avoid
swapping.) All builds with "gcc -O2".
> This makes me pretty
> pessimistic about the chances of a meaningful speedup here.
Yeah, this is confirmation that what you are seeing in the original test
is mostly about faulting pages in, not about the zeroing. I think it
would still be interesting to revisit the micro-optimization of
MemSet(), but it doesn't look like massive restructuring to avoid it
altogether is going to be worthwhile.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-11-29 17:53:18 | Re: PROPOSAL of xmlvalidate |
Previous Message | Jeff Janes | 2010-11-29 17:50:08 | Re: profiling connection overhead |