From: Arnaldo Carvalho de Melo <acme@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org, David Ahern <dsahern@gmail.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Mike Galbraith <efault@gmx.de>, Namhyung Kim <namhyung@gmail.com>,
Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <peterz@infradead.org>,
Stephane Eranian <eranian@google.com>
Subject: Re: [GIT PULL 00/13] Annotation improvements (G+ edition)
Date: Fri, 20 Apr 2012 07:59:02 -0300 [thread overview]
Message-ID: <20120420105902.GC9679@infradead.org> (raw)
In-Reply-To: <CA+55aFxY0MWR2vTRwf7a6+wm0gXet-X+i11=V_OapneciTJJMg@mail.gmail.com>
Em Thu, Apr 19, 2012 at 05:31:04PM -0700, Linus Torvalds escreveu:
> On Thu, Apr 19, 2012 at 1:33 PM, Arnaldo Carvalho de Melo wrote:
> Ok, so I did a quick test-run, and things are definitely more readable.
>
> However, from a "where is the loop" angle, the one thing that is
> actually fairly hard to visually see is the branches.
>
> Sure, you can find them, but they are not nearly as easy to pick out
> visually as the branch targets are, and I do wonder if it wouldn't
> make sense to try to make them stand out a bit more.
>
> What is visually important is
> (a) seeing that it's a branch
> (b) seeing the direction of the branch (to pick up on loops more easily).
>
> I suspect that doing a whole arrow is just going to be a horrible
> criss-crossing mess (although with some graphical UI it might not be
> as bad as with the textual one), but I think even just doing it in
> entirely local scope of the particular line that contains the branch
> would be perfectly fine.
You mean we could draw the arrow all the way from the branch to the
label when the cursor is on one of them (branch, label)?
It would avoid the criss-crossing mess, and with identing it would get
even easier to draw it, i.e. it would be a straight line with a tip just
below the branch and a "feather" just above the target label.
> This, for example, is a snippet of a pretty simple function
> (avc_lookup()) with a few branches and a few branch targets:
>
> 2.08 │ test %rdx,%rdx
> 0.00 │ jne 38
> 0.00 │ jmp 53
> 5.13 │ 30: mov (%rdx),%rdx
> 0.74 │ test %rdx,%rdx
> 0.00 │ je 53
> 0.06 │ 38: lea -0x20(%rdx),%rax
> 59.64 │ cmp -0x20(%rdx),%edi
> 0.40 │ jne 30
> 17.36 │ cmp -0x18(%rdx),%cx
> 0.00 │ jne 30
> 1.91 │ cmp 0x4(%rax),%esi
> 0.00 │ jne 30
> 0.22 │ test %rax,%rax
> 0.20 │ je 53
> 1.68 │ leaveq
> 1.90 │ retq
> 0.00 │ 53: incl %gs:0xe214
> 0.00 │ xor %eax,%eax
>
> and the branch targets are fairly easy to pick up, but seeing the
> branches - and their directions - themselves takes much more parsing.
> Ok, it's actually pretty simple above, because they have a faily
> obvious pattern, but in bigger functions they really are harder to
> pick out.
>
> Now, what if the branch instruction was just followed with a simple
> "arrow up/down" thing, and to make the distinction really simple to
> see visually, make the indentation slightly different for the
> back/forwards case, so that you don't have to really look at the
> (crappy) arrow head to find possible loops (backwards jumps).
>
> The above snippet would then become:
>
> 2.08 test %rdx,%rdx
> 0.00 jne 38 ----v
> 0.00 jmp 53 ----v
> 5.13 30: mov (%rdx),%rdx
> 0.74 test %rdx,%rdx
> 0.00 je 53 ----v
> 0.06 38: lea -0x20(%rdx),%rax
> 59.64 cmp -0x20(%rdx),%edi
> 0.40 jne 30 ----^
> 17.36 cmp -0x18(%rdx),%cx
> 0.00 jne 30 ----^
> 1.91 cmp 0x4(%rax),%esi
> 0.00 jne 30 ----^
> 0.22 test %rax,%rax
> 0.20 je 53 ----v
> 1.68 leaveq
> 1.90 retq
> 0.00 53: incl %gs:0xe214
> 0.00 xor %eax,%eax
>
> where I think it's fairly easy to pick up the branches. Sure, once you
> really need to connect them, you do need to compare the offsets (easy
> in the above case, less obvious with big complex functions), but just
> making it easy to *see* the backwards branches makes it easier to see
> the loop, methinks.
>
> I dunno. Just a suggestion. I definitely like the new format better
> already, regardless of any arrows.
Great, keep suggestions flowing. :-)
- Arnaldo
next prev parent reply other threads:[~2012-04-20 10:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-19 20:33 =?y?q?=5BGIT=20PULL=2000/13=5D=20Annotation=20improvements=20=28G+=20edition=29?= Arnaldo Carvalho de Melo
2012-04-19 20:33 ` [PATCH 01/13] perf annotate: Rename objdump_line to disasm_line Arnaldo Carvalho de Melo
2012-04-19 20:33 ` [PATCH 02/13] perf annotate: Parse instruction Arnaldo Carvalho de Melo
2012-04-19 23:55 ` David Ahern
2012-04-20 10:53 ` Arnaldo Carvalho de Melo
2012-04-23 6:30 ` Namhyung Kim
2012-04-19 20:33 ` [PATCH 03/13] perf annotate browser: Use the disasm_line instruction name and operand fields Arnaldo Carvalho de Melo
2012-04-19 20:33 ` [PATCH 04/13] perf annotate: Disassembler instruction parsing Arnaldo Carvalho de Melo
2012-04-19 20:34 ` [PATCH 05/13] perf annotate: Parse call targets earlier Arnaldo Carvalho de Melo
2012-04-19 20:34 ` [PATCH 06/13] perf annotate: Introduce scnprintf ins_ops method Arnaldo Carvalho de Melo
2012-04-19 20:34 ` [PATCH 07/13] perf annotate browser: Rename disasm_line_rb_node Arnaldo Carvalho de Melo
2012-04-19 20:34 ` [PATCH 08/13] perf symbols: Introduce symbol__size method Arnaldo Carvalho de Melo
2012-04-19 20:34 ` [PATCH 09/13] perf annotate browser: Hide non jump target addresses in offset mode Arnaldo Carvalho de Melo
2012-04-20 0:01 ` [GIT PULL 00/13] Annotation improvements (G+ edition) David Ahern
2012-04-20 10:51 ` Arnaldo Carvalho de Melo
2012-04-20 0:31 ` Linus Torvalds
2012-04-20 0:40 ` Linus Torvalds
2012-04-20 10:59 ` Arnaldo Carvalho de Melo [this message]
2012-04-25 7:05 ` Ingo Molnar
2012-04-25 10:31 ` Arnaldo Carvalho de Melo
2012-04-25 10:48 ` Arnaldo Carvalho de Melo
-- strict thread matches above, loose matches on Subject: below --
2012-04-23 1:17 George Spelvin
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=20120420105902.GC9679@infradead.org \
--to=acme@infradead.org \
--cc=dsahern@gmail.com \
--cc=efault@gmx.de \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@gmail.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
/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