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