-
Notifications
You must be signed in to change notification settings - Fork 65
PerfScore initial support #215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Added support for --perfscore to jit-diff.cs Added support for --count pass through to jit-analyze Changed default for --count from 5 to 20
|
Sample output: |
|
@dotnet/jit-contrib PTAL |
|
Is it useful to have "Top file regressions by perfScore" and "Top file improvements by perfScore"? Or is perfScore more useful as a per-function thing? You've used both "perfScore" and "perfscore" in the output. I would prefer to stick with one, consistently. Maybe "PerfScore" instead. |
|
Personally I find the per function information useful and I am fine with removing the per file perf scrore info. |
BruceForstall
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like you did a massive copy/paste/edit of code size to create all the perfscore code. Is there a way to share these? E.g., make code size or perf score an argument or generic argument to functions/class, so there's no duplication?
src/jit-analyze/jit-analyze.cs
Outdated
| DisplayMethodMetric("\nTop method regressions by size (percentage):", methodRegressionCount, sortedMethodRegressionsByPercentage); | ||
| DisplayMethodMetric("\nTop method improvements by size (percentage):", methodImprovementCount, sortedMethodImprovementsByPercentage); | ||
| DisplayMethodMetric("\nTop method regressions by codesize change (bytes):", methodRegressionCount, sortedMethodRegressions); | ||
| DisplayMethodMetric("\nTop method improvements by codesize change (bytes):", methodImprovementCount, sortedMethodImprovements); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you should write out "codesize" => "code size" and "perfscore" => "perf score" in the output
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will write out "code size" and "PerfScore" in the output
|
Refactoring to use generics and interfaces instead of simple code duplication requires a lot more time. |
remove "prolog bytes" use "code size" instead of "codesize"
|
I agree with Bruce here -- we will likely have other score-like metrics we want to aggregate/summarize in the future, and it would be better to generalize the pattern. |
|
To be a bit more specific, I am thinking about jit-diff and jit-analyze support for things like dotnet/coreclr#18330 ... right now it is clunky to count things across a large swath of jitted methods. |
|
I'll admit that looking at the duplication: my C# and LINQ knowledge is apparently not sophisticated enough to see an obvious code pattern to use to avoid the duplication. Anyone else have ideas here? The question is whether we should let this go in as-is, hoping to get it refactored later, or if we want to ensure it gets refactored now, which might mean it doesn't go in because it won't be prioritized. |
|
@BruceForstall Ping? |
|
I'll take a look at how we might avoid duplication -- though won't get to it until next week. |
Alternative take to dotnet#215 where jit-analyze is updated to look for and process multiple bits of metric data. With the pattern shown here it should be simple to add additional metrics like the ones we already have.
Alternative take to dotnet#215 where jit-analyze is updated to look for and process multiple bits of metric data. With the pattern shown here it should be simple to add additional metrics like the ones we already have.
Alternative take to #215 where jit-analyze is updated to look for and process multiple bits of metric data. Default is still code size, alternatives can be specified via `--metric <metricname>` With the pattern shown here it should be simple to add additional metrics like the ones we already have. Updated `jit-diff` to also support the `--metric` option.
|
@briansull Is there anything from this PR you want to preserve (and submit as a new PR), since #223 has been merged, with some/all of this functionality? |
|
I think so. I believe that the jit-diff changes are still need. |
I think I picked up all of your jit-diff changes in #223. |
I may be the source of the confusion. I wasn't able to find the option, but now I see that it's |
|
I added a --count N option to jit-diffs to allow us to override the count value of jit-analyze directly from jit-diff I didn't see that change. |
|
Should we close this PR since #223 addressed most of the part of this PR? |
It looks to me like we should. @briansull There is a |
Added support for --perfscore to jit-diff.cs
Added support for --count pass through to jit-analyze
Changed default for --count from 5 to 20