Re: Gather performance analysis

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Gather performance analysis
Date: 2021-09-08 07:40:44
Message-ID: CAFiTN-vgKTv=oyKmOsqJkRPWPpTcPMVARPDhhPwxV0tRRohsBA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 8, 2021 at 12:03 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2021-09-08 11:45:16 +0530, Dilip Kumar wrote:
> > On Wed, Sep 8, 2021 at 3:08 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> >
> >
> > > Looking at this profile made me wonder if this was a build without
> > > optimizations. The pg_atomic_read_u64()/pg_atomic_read_u64_impl() calls
> > > should
> > > be inlined. And while perf can reconstruct inlined functions when using
> > > --call-graph=dwarf, they show up like "pg_atomic_read_u64 (inlined)"
> for
> > > me.
> > >
> >
> > Yeah, for profiling generally I build without optimizations so that I can
> > see all the functions in the stack, so yeah profile results are without
> > optimizations build but the performance results are with optimizations
> > build.
>
> I'm afraid that makes the profiles just about meaningless :(.
>

Maybe it can be misleading sometimes, but I feel sometimes it is more
informative compared to the optimized build where it makes some function
inline, and then it becomes really hard to distinguish which function
really has the problem. But your point is taken and I will run with an
optimized build.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shinoda, Noriyoshi (PN Japan FSIP) 2021-09-08 07:52:35 RE: Improve logging when using Huge Pages
Previous Message Kyotaro Horiguchi 2021-09-08 07:40:33 Re: Possible missing segments in archiving on standby