From: Namhyung Kim <namhyung@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Taeung Song <treeze.taeung@gmail.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
linux-kernel@vger.kernel.org, Jiri Olsa <jolsa@kernel.org>,
Ingo Molnar <mingo@kernel.org>, Wang Nan <wangnan0@huawei.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Jiri Olsa <jolsa@redhat.com>,
kernel-team@lge.com
Subject: Re: [PATCH v2 2/3] perf annotate: Introduce the new source code view
Date: Fri, 3 Mar 2017 14:09:20 +0900 [thread overview]
Message-ID: <20170303050920.GK30710@sejong> (raw)
In-Reply-To: <20170301150746.GJ6515@twins.programming.kicks-ass.net>
Hi Peter,
On Wed, Mar 01, 2017 at 04:07:46PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 01, 2017 at 11:56:39PM +0900, Namhyung Kim wrote:
>
> > It's a kind of user experience issue. We provide the asm-only and
> > asm+source annotation, and I think it'd be nice to add source-only
> > option. And I remember that it was requested some time ago..
>
> Thing is, an optimizing compiler -- that same beast that ensures your
> objdump -S output is such a garbled mess -- can generate code that
> becomes very hard to relate to the original source code.
I understand that. Maybe it's not 100% accurate, but it still has
valuable information. And I think the source-only view can give more
readable outputs using the info. Also I guess many developers already
aware of the effect of optimizing compilers.
>
> I'm really sceptical the source line only view is very useful; maybe if
> you build with -O0, but then, if you do that you're not bothered with
> performance.
Even with an optimizing compiler, it can be helpful to overview which
parts of the code are bottlenecks IMHO. After that, one can see the
asm to identify the problem deeply, if needed.
Thanks,
Namhyung
next prev parent reply other threads:[~2017-03-03 6:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-28 19:59 [PATCH v2 0/3] perf annotate: Introduce the new source code view Taeung Song
2017-02-28 19:59 ` [PATCH v2 1/3] perf annotate: Get correct line numbers matched with addr Taeung Song
2017-03-01 13:17 ` Namhyung Kim
2017-03-02 6:05 ` Taeung Song
2017-03-03 2:40 ` Namhyung Kim
2017-03-03 3:25 ` Taeung Song
2017-02-28 19:59 ` [PATCH v2 2/3] perf annotate: Introduce the new source code view Taeung Song
2017-03-01 13:58 ` Namhyung Kim
2017-03-01 14:08 ` Peter Zijlstra
2017-03-01 14:21 ` Namhyung Kim
2017-03-01 14:30 ` Peter Zijlstra
2017-03-01 14:56 ` Namhyung Kim
2017-03-01 15:07 ` Peter Zijlstra
2017-03-01 15:52 ` Taeung Song
2017-03-03 5:09 ` Namhyung Kim [this message]
2017-02-28 19:59 ` [PATCH v2 3/3] perf annotate: Support the new source code view for TUI Taeung Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170303050920.GK30710@sejong \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=kernel-team@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=treeze.taeung@gmail.com \
--cc=wangnan0@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).