Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Date: 2013-01-13 20:44:58
Message-ID: 28180.1358109898@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-01-13 14:17:52 -0500, Tom Lane wrote:
>> I find these numbers pretty hard to credit.

> There are quite some elog(DEBUG*)s in the backend, and those are taken,
> so I don't find it unreasonable that doing less work in those cases is
> measurable.

Meh.  If there are any elog(DEBUG)s in time-critical places, they should
be changed to ereport's anyway, so as to eliminate most of the overhead
when they're not firing.

> And if you look at the disassembly of ERROR codepaths:

I think your numbers are being twisted by -fno-omit-frame-pointer.
What I get, with the __builtin_unreachable version of the macro,
looks more like

MemoryContextAlloc:
	cmpq	$1073741823, %rsi
	pushq	%rbx
	movq	%rsi, %rbx
	ja	.L53
	movq	8(%rdi), %rax
	movb	$0, 48(%rdi)
	popq	%rbx
	movq	(%rax), %rax
	jmp	*%rax
.L53:
	movl	$__func__.5262, %edx
	movl	$576, %esi
	movl	$.LC2, %edi
	call	elog_start
	movq	%rbx, %rdx
	movl	$.LC3, %esi
	movl	$20, %edi
	xorl	%eax, %eax
	call	elog_finish

With -fno-omit-frame-pointer it's a little worse, but still not what you
show --- in particular, for me gcc still pushes the elog calls out of
the main code path.  I don't think that the main path will get any
better with one elog function instead of two.  It could easily get worse.
On many machines, the single-function version would be worse because of
needing to use more parameter registers, which would translate into more
save/restore work in the calling function, which is overhead that would
likely be paid whether elog actually gets called or not.  (As an
example, in the above code gcc evidently isn't noticing that it doesn't
need to save/restore rbx so far as the main path is concerned.)

In any case, results from a single micro-benchmark on a single platform
with a single compiler version (and single set of compiler options)
don't convince me a whole lot here.

Basically, the aspects of this that I think are likely to be
reproducible wins across different platforms are (a) teaching the
compiler that elog(ERROR) doesn't return, and (b) reducing code size as
much as possible.  The single-function change isn't going to help on
either ground --- maybe it would have helped on (b) without the errno
problem, but that's going to destroy any possible code size savings.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2013-01-13 20:46:54
Subject: Re: logical changeset generation v3 - comparison to Postgres-R change set format
Previous:From: Dimitri FontaineDate: 2013-01-13 20:32:45
Subject: Re: ToDo: log plans of cancelled queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group