Re: Optimize memory allocation code
От | Tomas Vondra |
---|---|
Тема | Re: Optimize memory allocation code |
Дата | |
Msg-id | 20201003205703.6ot5gc6cxxlzepfb@development обсуждение исходный текст |
Ответ на | Re: Optimize memory allocation code (Merlin Moncure <mmoncure@gmail.com>) |
Список | pgsql-hackers |
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@hotmail.com> wrote: >> >> >> >> > On Sep 26, 2020, at 8:09 AM, Julien Rouhaud <rjuju123@gmail.com> wrote: >> > >> > Hi, >> > >> > On Sat, Sep 26, 2020 at 12:14 AM Li Japin <japinli@hotmail.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). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: