Closed jakobbotsch closed 6 months ago
any opposing opinions?
I would like to register one: I like the method names first because they're usually the most interesting thing to look at.
I would not have any objections to making the change's output the default, though.
Is there a balance we could strike here?
Maybe
ShortName | InsCountDiff | InsPercentageDiff | ContributionPercentage | FullName
So for example, rather than:
public: void __cdecl GcInfoEncoder::Build(void) : 23837106 : +39.24% : 30.26% : +0.2190%
or
23837106 : +39.24% : 30.26% : +0.2190% : public: void __cdecl GcInfoEncoder::Build(void)
We could do:
GcInfoEncoder::Build : 23837106 : +39.24% : 30.26% : +0.2190% : public: void __cdecl GcInfoEncoder::Build(void)
Which avoids parameters/return/types/etc shifting important data extremely far to the right, while still giving quick contextual access to a key piece of information (the name)
I don't think there is a need to complicate the tool with method name parsing, which is not always possible. The method name could be any of "fully mangled", "lightly demangled" (like in the documentation for the tool), "fully demangled" (like in Jakob's example), or even "missing" (if you don't have the debug symbols for whichever reason).
I'll just keep this locally.
Since the name field is always the longest I think it makes things easier to read if it is on the right.
Example base:
Example diff:
cc @dotnet/jit-contrib @SingleAccretion any opposing opinions? If so I can add an option, but if everyone agrees...