[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mwbbfnj2.fsf@sejong.aot.lge.com>
Date: Mon, 11 Aug 2014 17:17:37 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...nel.org>,
Paul Mackerras <paulus@...ba.org>,
Namhyung Kim <namhyung.kim@....com>,
LKML <linux-kernel@...r.kernel.org>, Jiri Olsa <jolsa@...hat.com>
Subject: Re: [PATCH 8/8] perf symbol: Don't demangle parameters and such by default
On Sat, 2 Aug 2014 10:35:03 -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jul 31, 2014 at 02:47:42PM +0900, Namhyung Kim escreveu:
>> Some C++ symbols have very long name and they make column length
>> longer. Most of them are about parameters including templates and we
>> can ignore such info most of time IMHO.
>>
>> This patch passes DMGL_NO_OPTS by default when calling bfd_demangle().
>> One can still see full symbols with -v/--verbose option.
>>
>> before:
>> JS_CallFunctionValue(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::Value*)
>>
>> after:
>> JS_CallFunctionValue
>
> Are you sure we want that?
>
> With this we'll end up having different instantiations having the same
> name, since the way to differentiate them is exactly by a different
> parameter list, no?
Right, but I think it's not a big problem since such overloaded
functions will not be shown at the same time as only one of them might
do the real work most cases. Simply noticing one of them is a
performance bottle neck would be helpful to the developer, I guess.
Even if it's not the case, one still can see and identify the correct
one using the -v option.
For me, it's just annoying when (unimportant) C++ symbols occupy too
much space in a limited terminal width.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists