|From:||Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>|
|To:||Merlin Moncure <mmoncure(at)gmail(dot)com>|
|Cc:||Li Japin <japinli(at)hotmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Optimize memory allocation code|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Fri, Sep 25, 2020 at 07:37:07PM -0500, Merlin Moncure wrote:
>On Fri, Sep 25, 2020 at 7:32 PM Li Japin <japinli(at)hotmail(dot)com> wrote:
>> > On Sep 26, 2020, at 8:09 AM, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>> > Hi,
>> > On Sat, Sep 26, 2020 at 12:14 AM Li Japin <japinli(at)hotmail(dot)com> wrote:
>> >> Hi, hackers!
>> >> I find the palloc0() is similar to the palloc(), we can use palloc() inside palloc0()
>> >> to allocate space, thereby I think we can reduce duplication of code.
>> > The code is duplicated on purpose. There's a comment at the beginning
>> > that mentions it:
>> > /* duplicates MemoryContextAllocZero to avoid increased overhead */
>> > Same for MemoryContextAllocZero() itself.
>> Thanks! How big is this overhead? Is there any way I can test it？
>Profiler. For example, oprofile. In hot areas of the code (memory
>allocation is very hot), profiling is the first step.
Maybe a micro-benchmark would be better, e.g. a function with a loop
doing many palloc/palloc0 calls, or something similar.
FWIW I wonder what kind of overhead is this meant to avoid, the comment
unfortunaly does not go into any details. I suppose it's to not do extra
function calls, but maybe there's something else going on. And maybe the
overhead is much lower on modern CPUs (although this seems to come from
8396447cdbd in 2013, so it's not that old).
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Rémi Lapeyre||2020-10-03 21:42:52||Re: Add header support to text format and matching feature|
|Previous Message||Alexander Korotkov||2020-10-03 20:13:28||Re: POC: contrib/unaccent as IMMUTABLE|