Repository navigation
[Perf -196%] System.Collections.ContainsTrue<Int32> (6) #41167
Description
Run Information
| Architecture | x86 |
|---|---|
| OS | Windows 10.0.18362 |
| Changes | diff |
Regressions in System.Collections.ContainsTrue<Int32>
| Benchmark | Baseline | Test | Test/Base | Modality | Baseline Outlier |
|---|---|---|---|---|---|
| Array | 41.69 μs | 121.84 μs | 2.92 | True | |
| ImmutableArray | 43.10 μs | 116.85 μs | 2.71 | False | |
| List | 40.60 μs | 121.31 μs | 2.99 | True | |
| Queue | 41.12 μs | 121.74 μs | 2.96 | True | |
| ICollection | 40.48 μs | 120.94 μs | 2.99 | True | |
| Span | 38.31 μs | 121.30 μs | 3.17 | False |
Historical Data in Reporting System
_1.png)
_2.png)
_3.png)
_4.png)
_5.png)
_6.png)
Repro
git clone https://github.com/dotnet/performance.git
py .\performance\scripts\benchmarks_ci.py -f netcoreapp5.0 --filter 'System.Collections.ContainsTrue<Int32>*';Details
Histogram
System.Collections.ContainsTrue.Array(Size: 512)
[ 37830.974 ; 44220.358) | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[ 44220.358 ; 50609.743) |
[ 50609.743 ; 56999.127) |
[ 56999.127 ; 63388.512) |
[ 63388.512 ; 69777.896) |
[ 69777.896 ; 76167.281) |
[ 76167.281 ; 82556.665) |
[ 82556.665 ; 88946.050) |
[ 88946.050 ; 95335.434) |
[ 95335.434 ; 101724.819) |
[101724.819 ; 108114.203) |
[108114.203 ; 115700.072) |
[115700.072 ; 122089.456) | @@@@@@@@@
System.Collections.ContainsTrue.ImmutableArray(Size: 512)
[ 39931.110 ; 45983.331) | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[ 45983.331 ; 52035.551) |
[ 52035.551 ; 58087.772) |
[ 58087.772 ; 64139.992) |
[ 64139.992 ; 70192.213) |
[ 70192.213 ; 76244.433) |
[ 76244.433 ; 82296.654) |
[ 82296.654 ; 88348.874) |
[ 88348.874 ; 94401.095) |
[ 94401.095 ; 100453.315) |
[100453.315 ; 106505.535) |
[106505.535 ; 114017.398) |
[114017.398 ; 120282.927) | @@@@@@@@@
System.Collections.ContainsTrue.List(Size: 512)
[ 37081.144 ; 43571.129) | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[ 43571.129 ; 50061.114) |
[ 50061.114 ; 56551.100) |
[ 56551.100 ; 63041.085) |
[ 63041.085 ; 69531.070) |
[ 69531.070 ; 76021.056) |
[ 76021.056 ; 82511.041) |
[ 82511.041 ; 89001.026) |
[ 89001.026 ; 95491.012) |
[ 95491.012 ; 101980.997) |
[101980.997 ; 108470.982) |
[108470.982 ; 115647.215) |
[115647.215 ; 122137.200) | @@@@@@@@@
System.Collections.ContainsTrue.Queue(Size: 512)
[ 38137.016 ; 44550.932) | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[ 44550.932 ; 50964.849) |
[ 50964.849 ; 57378.765) |
[ 57378.765 ; 63792.681) |
[ 63792.681 ; 70206.597) |
[ 70206.597 ; 76620.514) |
[ 76620.514 ; 83034.430) |
[ 83034.430 ; 89448.346) |
[ 89448.346 ; 95862.262) |
[ 95862.262 ; 102276.179) |
[102276.179 ; 108690.095) |
[108690.095 ; 115921.666) |
[115921.666 ; 122335.582) | @@@@@@@@@
System.Collections.ContainsTrue.ICollection(Size: 512)
[ 37234.692 ; 43644.541) | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[ 43644.541 ; 50054.389) |
[ 50054.389 ; 56464.238) |
[ 56464.238 ; 62874.086) |
[ 62874.086 ; 69283.935) |
[ 69283.935 ; 75693.783) |
[ 75693.783 ; 82103.632) |
[ 82103.632 ; 88513.480) |
[ 88513.480 ; 94923.329) |
[ 94923.329 ; 101333.177) |
[101333.177 ; 107743.026) |
[107743.026 ; 115217.905) |
[115217.905 ; 121627.753) | @@@@@@@@@
System.Collections.ContainsTrue.Span(Size: 512)
[ 34357.683 ; 41646.559) | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[ 41646.559 ; 48421.977) |
[ 48421.977 ; 55197.395) |
[ 55197.395 ; 61972.813) |
[ 61972.813 ; 68748.231) |
[ 68748.231 ; 75523.650) |
[ 75523.650 ; 82299.068) |
[ 82299.068 ; 89074.486) |
[ 89074.486 ; 95849.904) |
[ 95849.904 ; 102625.322) |
[102625.322 ; 109400.741) |
[109400.741 ; 118252.968) |
[118252.968 ; 125394.354) | @@@@@@@@@
Docs
Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository
Reacted by Adam Sitnik
Activity
DrewScoggins commentedon Aug 21, 2020
From @adamsitnik
It looks like a 32-bit only regression (both ARM and x86).
System.Collections.ContainsTrue.ICollection(Size: 512)
danmoseley commentedon Aug 21, 2020
@DrewScoggins I think your diff link above is correct, and matches the x axis on the graph -- it was 6pm 5/9 through midnight. But if I zoom on the graph and do the usual selection of points, it gives me a much wider range -- af1db3e...e18250b
Do you get the same result from the graph?
DrewScoggins commentedon Aug 21, 2020
That's because the linked report was run against the installer repo, and since we don't take a lot of updates to the runtime in that repo there can often be big gaps in what runtime is being tested. Since this was such a big gap, I used this link, Array, to try and get a tighter bound for the test.
danmoseley commentedon Aug 21, 2020
Why is that graph tighter?
Also, it show May 9 08:26 3cd02df through 14:41 6b5850f which gives me 4 commits -- 3cd02df...6b5850f
your diff is e77572f...d2f7c8f which strraddles 10 commits.
Am I doing it wrong?
DrewScoggins commentedon Aug 21, 2020
That graph is tighter because those runs are from the runtime repo and not the installer repo. So we run closer to every commit. The reason your bound is tighter is that you are better at clicking then I am ;)
danmoseley commentedon Aug 21, 2020
What is the difference bewteen runtime repo and installer repo runs? If we have the former why do we do the latter, and the results link above is to the latter?
Anyway it's a puzzle as nothing in any of these commit ranges looks suspicions. I also see the perf scenario did not change.
danmoseley commentedon Aug 21, 2020
Given it's 32 bit only, and all collections are affected, my suspicion is codegen. But there's almost no code in common between these scenarios!
From https://pvscmdupload.blob.core.windows.net/reports/08_20_2020/report_Daily_ca=x86_cb=master_co=Windows1018362_cr=dotnetcoresdk_cc=CompliationMode=tiered-RunKind=micro_Baseline_bb=release-3.1.1xx_2020-08-20.html it's affecting
ContainsFalse<Int32>the same. It's also affectingContainsTrue<string>.Seems unlikely, but if we got our diff a bit wrong, this commit could be implicated?
57408d0
@CarolEidt can you imagine how this would affect this scenario?
danmoseley commentedon Aug 21, 2020
@DrewScoggins were there any other scenarios regressed in this range, other than ContainsTrue/ContainsFalse?
10 remaining items
danmoseley commentedon Aug 22, 2020
aha 3cd02df...6b5850f#diff-bc54f7594b794b8bff2eedbf3347aaa6L367
danmoseley commentedon Aug 22, 2020
Never mind, subtraction has precedence over comparison operators, but it was clearer before with the parentheses.
Fix perf regression in IntPtr operators on 32-bit platforms
Fix perf regression in IntPtr operators on 32-bit platforms (#41198)
Fix perf regression in IntPtr operators on 32-bit platforms (#41254)
danmoseley commentedon Aug 24, 2020
I would still like to understand this @DrewScoggins @adamsitnik .. not interested in blaming anyone 😁 just making sure we understand and can improve our processes if necessary. thoughts?
adamsitnik commentedon Aug 24, 2020
The issue was reported by the bot in June: DrewScoggins/performance-2#910 (comment)
We meet once a week with Drew, Tanner, Andy an Kunal and go throught the list of all reported issues. We have most probably not discussed this particular one (human error).
I've confirmed it during my independent verificaiton: DrewScoggins/performance-2#910 (comment) and @DrewScoggins moved it here.
So far this was the only issue like this, all other x86 and x64 issues were already reported (in general the initial results of my verification looks very promissing).
My plan is to send a report when I am done and also a PR to the bot repo that adds all the actual regressions as unit tests to ensure that we don't loose the precision over time. @danmosemsft does it sound good to you?
danmoseley commentedon Aug 24, 2020
Sounds good! Again, just interested in ways we can continue to help remove opportunities for error from our processes, as we go along. Thanks!