Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
От | Tom Lane |
---|---|
Тема | Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4) |
Дата | |
Msg-id | 1514.1357764199@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] unified frontend support for pg_malloc et al and
palloc/pfree mulation (was xlogreader-v4)
|
Список | pgsql-hackers |
I wrote: > I then applied the palloc.h and mcxt.c hunks of your patch and rebuilt. > Now I get an average runtime of 16666 ms, a full 2% faster, which is a > bit astonishing, particularly because the oprofile results haven't moved > much: I studied the assembly code being generated for palloc(), and I believe I see the reason why it's a bit faster: when there's only a single local variable that has to survive over the elog call, gcc generates a shorter function entry/exit sequence. I had thought of proposing that we code palloc() like this: void * palloc(Size size) { MemoryContext context = CurrentMemoryContext; AssertArg(MemoryContextIsValid(context)); if (!AllocSizeIsValid(size)) elog(ERROR, "invalid memory alloc request size %lu", (unsigned long) size); context->isReset = false; return (*context->methods->alloc) (context, size); } but at least on this specific hardware and compiler that would evidently be a net loss compared to direct use of CurrentMemoryContext. I would not put a lot of faith in that result holding up on other machines though. In any case this doesn't explain the whole 2% speedup, but it probably accounts for palloc() showing as slightly cheaper than MemoryContextAlloc had been in the oprofile listing. regards, tom lane
В списке pgsql-hackers по дате отправления: