lkml.org 
[lkml]   [2012]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL 0/5] perf/annotate fixes and improvements
    Em Thu, May 03, 2012 at 10:01:40AM +0200, Peter Zijlstra escreveu:
    > On Wed, 2012-05-02 at 18:18 -0300, Arnaldo Carvalho de Melo wrote:
    > > I.e. the fixed vertical line now has a diff color and the jump arrows are
    > > _after_ the jump labels that then stands out as a separated columns.
    >
    > Note that if you have the source-code annotated thing enabled (which
    > seems to be the default) the arrows go straight through the source.

    I thought I had that fixed, damn, will fix.

    > Also, in this case the asm is dark blue, which is nearly invisible on my
    > black background.

    What colour do you suggest? Also what kind of term color scheme do you
    use? Finding the right default combo is kinda hard.

    > > In addition, as you suggested, the extra arrows on the ends of a jump->label
    > > arrow gets swallowed by the jump->label arrow.
    >
    > Does look nice, thanks!
    >
    > An alternative to all this arrow drawing could be to high-light the
    > jump-target, maybe not a full bar like the cursor line but something
    > like that.
    >
    > Also, is there a key to jump to the jump target? I was instinctively
    > pressing '%' to do that, but that could be my vim brain-damage :-)

    Enter or ->, just like on calls and rets, what is missing is using <- to
    go back the stack of navigated jumps, like with calls.

    > > Now a question: when I add multiple event column overheads, do you think we
    > > should have N fixed vertical lines separating them?
    >
    > I'd start with that and go from there.

    Ok

    > > I probably need to add an space before the instructions and the arrow
    > > start/end, or not?
    >
    > Since its a dynamic arrow (in a nearly invisible colour) it doesn't
    > really matter. But what happens when a function is large enough that
    > function offset doesn't fit in 2 hex digits anymore? Aah I see, that
    > width is dynamic, OK.

    Yes, it is, it is calculated at function start and when switching
    to/from "O"ffset view.

    I need to add a help window with the ever growing list of hot keys.

    Also will try to asap make the last features toggled persistent.

    - Arnaldo


    \
     
     \ /
      Last update: 2012-05-03 15:41    [W:0.023 / U:1.916 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site