From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Li Japin <japinli(at)hotmail(dot)com> |
Cc: | 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 |
Date: | 2020-09-26 00:37:07 |
Message-ID: | CAHyXU0ySj1c07RwcuiMKGJD+yTD+RFZq0tyK+M4ooPT5xf3UpQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-09-26 05:03:37 | Re: a potential size overflow issue |
Previous Message | Li Japin | 2020-09-26 00:32:28 | Re: Optimize memory allocation code |