Open performanceautofiler[bot] opened 2 years ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
This is the commit range, https://github.com/dotnet/runtime/compare/a077f271c3b5a8487f94111dc00a404a01fdc86b...6af4abc5a0db0560e719539a869233d15d28dc09. We could not easily understand where the issue was coming from.
@jeffschwMSFT Did you see something that made you tag this as pipelines? The tests affected don't seem to be pipeline related.
In this case, I choose a label for one of the PRs that is in the range above. Closest to IO was pipelines. (nothing deeper than that)
This is the commit range, a077f27...6af4abc. We could not easily understand where the issue was coming from.
@DrewScoggins The commit range included in the first post in this issue is a different (bigger) range: https://github.com/dotnet/runtime/compare/64807b3ccdc22da1175aa1bc1777d3abb1d9306f...9342649430c19af4bc9fe0d870609778f244a721
That range includes some arm64 changes that might be more likely to cause this (for instance, I see a peephole opt was removed on arm64).
I downloaded the attached artifacts and checked the commit hashes on libcoreclr and they match what was reported by the bot. Is the bot incorrect here about the versions used during the test? Or did you run additional tests to narrow down when the regression occurred (and if so, can you narrow it down even further? :smile:)?
Sorry for the delayed response, I had a filter that was a little too aggressive.
The way that we create the diff range is through the use of a changepoint algorithm. When that algorithm finds a change point, it does not always find it exactly. It can sometimes be a point off. This is a limitation of the algorithm. So to counter act this the diff link that is included in the issue goes one commit back and one commit forward to make sure that link has a higher chance of including the regression. The range that was found and included was obtained by using a feature in the reports that allows you to click a point and set it as a baseline, and click another point after it to set a compare, and then get a link to the commit range between those two points. Since that is done manually we can get as tight a range as possible.
Thanks for that explanation @DrewScoggins. In this case, I think the commit range is likely wrong given the tests affected and the fact that it's arm64-specific.
@AndyAyersMS Any chance this arm64 regression is related to https://github.com/dotnet/runtime/pull/68631 ?
@AndyAyersMS Any chance this arm64 regression is related to #68631 ?
Extremely unlikely.
Based on multiple charts the implicated commit range is indeed https://github.com/dotnet/runtime/compare/a077f271c3b5a8487f94111dc00a404a01fdc86b...6af4abc5a0db0560e719539a869233d15d28dc09
These regressions have persisted so they look real.
Ubuntu x64 shows a regression at the same spot (sorry my x axis span keeps shifting; @DrewScoggins it sure would be nice if we had an easy way of getting multiple charts over the same time range) so perhaps this is unix specific? Windows results are noisy but don't show a regression here.
The only possibilities I see in that commit range are https://github.com/dotnet/runtime/pull/68210 or https://github.com/dotnet/runtime/pull/68457 and it's not obvious either of them is involved.
So somebody needs to grab some before and after builds and drill into these tests to see what is going on.
Thanks @AndyAyersMS
Tagging subscribers to this area: @dotnet/area-system-memory See info in area-owners.md if you want to be subscribed.
Author: | performanceautofiler[bot] |
---|---|
Assignees: | DrewScoggins |
Labels: | `area-System.Memory`, `tenet-performance`, `tenet-performance-benchmarks`, `untriaged`, `refs/heads/main`, `ubuntu 18.04`, `RunKind=micro`, `Regression`, `CoreClr`, `arm64` |
Milestone: | - |
Tagging subscribers to this area: @dotnet/area-system-io See info in area-owners.md if you want to be subscribed.
Author: | performanceautofiler[bot] |
---|---|
Assignees: | DrewScoggins |
Labels: | `area-System.IO`, `tenet-performance`, `tenet-performance-benchmarks`, `untriaged`, `refs/heads/main`, `ubuntu 18.04`, `RunKind=micro`, `Regression`, `CoreClr`, `arm64` |
Milestone: | - |
I took a look at the charts, and I currently can't see any explanation why these benchmarks could slow down.
This regression is Linux specific, there were no changes related to IO during this period.
@DrewScoggins is there any chance the Linux machines get somehow updated?
Run Information
Regressions in System.IO.Tests.Perf_File
Test Report
Repro
Run Information
Regressions in System.IO.Tests.Perf_Path
Test Report
Repro
Run Information
Regressions in System.IO.Tests.Perf_FileInfo
Test Report
Repro
Run Information
Regressions in System.IO.Tests.Perf_Directory
Test Report
Repro