Re: [PATCHSET 0/3] perf diff: Introduce delta-abs compute method

[Namhyung Kim <namhyung@kernel.org>]

Hi Arnaldo,

On Tue, Feb 07, 2017 at 01:02:14PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Feb 06, 2017 at 11:26:16PM +0900, Namhyung Kim escreveu:
> > Hi Arnaldo,
> > 
> > On Mon, Feb 06, 2017 at 09:51:49AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Feb 06, 2017 at 04:20:34PM +0900, Namhyung Kim escreveu:
> > > I agree on having the default changed to 'delta-abs', Ingo?
>  
> > Good.  Also, as I said in the changelog, it needs to change default
> > value of -o option to 1 in order to make the 'delta-abs' effective.
> 
> ok
>  
> > > Namhyung, and perhaps we should have a single letter option to do that
> > > '| grep -v ^#' bit :-) and perhaps we also should have, for all tools
> > > the equivalent of that "| head", that git log has:
> > > 
> > > [acme@jouet linux]$ git log --oneline -5
> > > d7cb3a507d23 Merge tag 'perf-core-for-mingo-4.11-20170201' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
> > > 5443624bedd0 perf/x86/intel/pt: Add format strings for PTWRITE and power event tracing
> > > b05d1093987a perf ftrace: Add ftrace.tracer config option
> > > 43d41deb71fe perf tools: Create for_each_event macro for tracepoints iteration
> > > a26305363d4b perf test: Add libbpf pinning test
> > > [acme@jouet linux]$
> > > 
> > > That '-5' to show just the first 5 lines worth of output.
> > > 
> > > With all that we would have:
> > > 
> > >   perf diff -o 1 -q10
> > > 
> > > As the equivalent to "perf diff -o 1 -c delta-abs | grep -v ^# | head".
> > 
> > The -q/--quiet looks ok since it corresponds to -v/--verbose option.
> 
> Ok, agreed on this one.
> 
> > But I'm not sure about the number option.
>  
> > In case of git, it'll stop processing commits after the given number
> > of them, so it will reduce significant processing time IMHO.  However,
> > in perf, we need to process whole data anyway and sort at the final
> > stage, and then stop displaying entries after the given number.
>  
> > Maybe it's just a shortcut of piping to the head command.  Then I
> 
> I wasn't thinking about the processing savings from stopping to process
> at that many lines, my suggestion was just about making the command line
> more compact, to type less.
> 
> If that can also map to processing savings, the better.

Ok, I'll take a look at it later.  I just want to finish this work first.

Thanks,
Namhyung