-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Regressions in System.Buffers.Tests.RentReturnArrayPoolTests<Object> #72194
Comments
Run Information
Regressions in System.Buffers.Tests.ReadOnlySequenceTests<Byte>
Reprogit clone https://github.com/dotnet/performance.git
py .\performance\scripts\benchmarks_ci.py -f net6.0 --filter 'System.Buffers.Tests.ReadOnlySequenceTests<Byte>*' PayloadsHistogramSystem.Buffers.Tests.ReadOnlySequenceTests<Byte>.FirstSpanTenSegments
Description of detection logic
DocsProfiling workflow for dotnet/runtime repository |
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. |
All the above regressions have been solved except for System.Buffers.Tests.RentReturnArrayPoolTests MultipleSerial and SingleParallel Edit: I was mistaken, all benchmarks listed above have regressed |
Tagging subscribers to this area: @dotnet/area-system-buffers Issue DetailsRun Information
Regressions in System.Text.Json.Tests.Perf_Deep
Reprogit clone https://github.com/dotnet/performance.git
py .\performance\scripts\benchmarks_ci.py -f net6.0 --filter 'System.Text.Json.Tests.Perf_Deep*' PayloadsHistogramSystem.Text.Json.Tests.Perf_Deep.WriteDeepUtf16(Formatted: False, SkipValidation: True)
Description of detection logic
Description of detection logic
Description of detection logic
DocsProfiling workflow for dotnet/runtime repository
Regressions in System.Text.Json.Tests.Perf_Basic
Reprogit clone https://github.com/dotnet/performance.git
py .\performance\scripts\benchmarks_ci.py -f net6.0 --filter 'System.Text.Json.Tests.Perf_Basic*' PayloadsHistogramSystem.Text.Json.Tests.Perf_Basic.WriteBasicUtf16(Formatted: False, SkipValidation: True, DataSize: 100000)
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
DocsProfiling workflow for dotnet/runtime repository Run Information
Regressions in System.Buffers.Tests.RentReturnArrayPoolTests<Object>
Reprogit clone https://github.com/dotnet/performance.git
py .\performance\scripts\benchmarks_ci.py -f net6.0 --filter 'System.Buffers.Tests.RentReturnArrayPoolTests<Object>*' PayloadsHistogramSystem.Buffers.Tests.RentReturnArrayPoolTests<Object>.MultipleSerial(RentalSize: 4096, ManipulateArray: False, Async: False, UseSharedPool: False)
Description of detection logic
Description of detection logic
DocsProfiling workflow for dotnet/runtime repository Run Information
Regressions in System.Buffers.Text.Tests.Utf8FormatterTests
Reprogit clone https://github.com/dotnet/performance.git
py .\performance\scripts\benchmarks_ci.py -f net6.0 --filter 'System.Buffers.Text.Tests.Utf8FormatterTests*' PayloadsHistogramSystem.Buffers.Text.Tests.Utf8FormatterTests.FormatterInt32(value: 12345)
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
DocsProfiling workflow for dotnet/runtime repository Run Information
Regressions in System.Collections.Concurrent.Count<String>
Reprogit clone https://github.com/dotnet/performance.git
py .\performance\scripts\benchmarks_ci.py -f net6.0 --filter 'System.Collections.Concurrent.Count<String>*' PayloadsHistogramSystem.Collections.Concurrent.Count<String>.Queue(Size: 512)
Description of detection logic
Description of detection logic
DocsProfiling workflow for dotnet/runtime repository Run Information
Regressions in System.Buffers.Tests.ReadOnlySequenceTests<Char>
Reprogit clone https://github.com/dotnet/performance.git
py .\performance\scripts\benchmarks_ci.py -f net6.0 --filter 'System.Buffers.Tests.ReadOnlySequenceTests<Char>*' PayloadsHistogramSystem.Buffers.Tests.ReadOnlySequenceTests<Char>.FirstSpanTenSegments
Description of detection logic
DocsProfiling workflow for dotnet/runtime repository
|
This regression was detected by our August Performance report: System.Buffers.Tests.RentReturnArrayPoolTests.ProducerConsumer(RentalSize: 4096, ManipulateArray: False, Async: True, UseSharedPool: True)
|
@AndyAyersMS Thoughts on these regressions? Given this is a PGO update should we assume this is by design and close this issue? Or should we investigate this further. Specifically, System.Buffers.Tests.RentReturnArrayPoolTests MultipleSerial and SingleParallel and the one Mukund flagged above. |
Have we isolated this to the PGO udpate? If not, we should probably drill in. |
@AndyAyersMS I'm unsure if we have 100% isolated this to PGO. Looking at the commit range (52f4e7c...8fe39db), I've gotten some more insight. First of all, considering these tests have not regressed on Windows x64, it seems like this is arm64 specific. In my opinion, that rules out commits like #71302 which should affect all configs, right? On that note, could the PGO update only affect arm64? Otherwise, the only other arm64 specific commit I see in that range is #71306, which doesn't seem like it should affect this. |
Actually, looking at your comment here dotnet/perf-autofiling-issues#6480 (comment), it could be caused by #71161. |
Seems possible but unlikely -- diffs from #71161 are no longer available so hard to say for sure. @jakobbotsch any chance you could take a look? In the lab we only see this regression (June 27) on the ampere ubuntu arm64 runs, so it's not all arm64 HW either. |
Hottest methods via PGO data (sum of basic block counts): System.Buffers.ConfigurableArrayPool`1+Bucket[System.__Canon].Return: 152000000
System.Buffers.ConfigurableArrayPool`1+Bucket[System.__Canon].Rent: 136800008
System.Threading.SpinLock.Enter: 121600000
System.Buffers.ConfigurableArrayPool`1[System.__Canon].Rent: 106400000
System.Buffers.Tests.RentReturnArrayPoolTests`1+<MultipleSerial>d__23[System.__Canon].MoveNext: 104500133
System.Numerics.BitOperations.Log2: 91200123
System.Buffers.ConfigurableArrayPool`1[System.__Canon].Return: 91200000
System.Threading.SpinLock.Exit: 60800000
System.ArgumentNullException.ThrowIfNull: 30413678
System.Type.op_Equality: 153018
System.Runtime.CompilerServices.CastHelpers.IsInstanceOfClass: 113322
System.Diagnostics.Debug.Assert: 82844
Perfolizer.Mathematics.Distributions.StudentDistribution.StudentTwoTail: 69354
... Comparing 52f4e7c (left) to 8fe39db (right): https://www.diffchecker.com/BfH1vTmK ; Assembly listing for method Bucket[__Canon][System.__Canon]:Return(System.__Canon[]):this
; Emitting BLENDED_CODE for generic ARM64 CPU - Unix
; Tier-1 compilation
; optimized code
; fp based frame
; fully interruptible
; No PGO data
-; 2 inlinees with PGO data; 6 single block inlinees; 0 inlinees without PGO data
+; 1 inlinees with PGO data; 6 single block inlinees; 1 inlinees without PGO data ; Assembly listing for method Bucket[__Canon][System.__Canon]:Rent():System.__Canon[]:this
; Emitting BLENDED_CODE for generic ARM64 CPU - Unix
; Tier-1 compilation
; optimized code
; fp based frame
; fully interruptible
; No PGO data
-; 2 inlinees with PGO data; 5 single block inlinees; 0 inlinees without PGO data
+; 1 inlinees with PGO data; 5 single block inlinees; 1 inlinees without PGO data
; Final local variable assignments and these two methods are the only ones with significant diffs (looks like some BB reordering). |
Interesting. We should try and root cause what's behind this...
I'll start in on this, but @jakobbotsch feel free to jump in if you have some of this lying around. |
I'm currently deep in some of my quality week work, but I can try to look into the dumps tomorrow if you haven't root caused it by then. One thing I just realized is that I did the above investigation with a checked SPC, so it may have contributed to failures in matching up PGO data... (though I would expect to see it in both base and diff) |
Ok, I'll let you know how far I get. |
My local profile shows:
So indeed, bucket Rent/Return are dominant. A few interesting tidbits:
|
With release builds (and checked jit) I don't see any codegen diff at Tier1 for Going to check some of the other methods noted above. |
Also very odd:
|
One small asm diff in as do the move nexts |
I still see significant diffs in
Diffs: https://www.diffchecker.com/D7VI2RXp (52f4e7c on the left, 8fe39db on the right) |
There's no PGO info for *************** Inline @[000018] Starting PHASE Profile incorporation
-Have static profile data: 5 schema records (schema at 00000000D1FFAB1E, data at 00000000D1FFAB1E)
-Profile summary: 2 runs, 0 block probes, 4 edge probes, 0 class profiles, 0 method profiles, 0 other records
-
-Reconstructing block counts from sparse edge instrumentation
-... adding known edge BB15 -> BB17: weight 0
-... adding known edge BB16 -> BB17: weight 0
-... adding known edge BB16 -> BB18: weight 2
-... adding known edge BB18 -> BB14: weight 2
-
-New BlockSet epoch 2, # of blocks (including unused BB00): 19, bitset array size: 1 (short)
- ... unknown edge BB14 -> BB15
- ... unknown edge BB14 -> BB17
- ... unknown edge BB17 -> BB18
- ... unknown edge BB15 -> BB16
-
-Solver: 5 blocks, 5 unknown; 8 edges, 4 unknown, 0 zero (and so ignored)
-
-Pass [1]: 5 unknown blocks, 4 unknown edges
-BB18: 1 incoming unknown, 0 outgoing unknown
-BB18: all outgoing edge weights known, summming...
- BB18 -> BB14 has weight 2
-BB18: all outgoing edge weights known, sum is 2
-BB17 -> BB18: target block weight and all other incoming edge weights known, so weight is 0
-BB17: 1 incoming unknown, 0 outgoing unknown
-BB17: all outgoing edge weights known, summming...
- BB17 -> BB18 has weight 0
-BB17: all outgoing edge weights known, sum is 0
-BB14 -> BB17: target block weight and all other incoming edge weights known, so weight is 0
-BB16: 1 incoming unknown, 0 outgoing unknown
-BB16: all outgoing edge weights known, summming...
- BB16 -> BB17 has weight 0
- BB16 -> BB18 has weight 2
-BB16: all outgoing edge weights known, sum is 2
-BB15 -> BB16: target block weight and all other incoming edge weights known, so weight is 2
-BB15: 1 incoming unknown, 0 outgoing unknown
-BB15: all outgoing edge weights known, summming...
- BB15 -> BB17 has weight 0
- BB15 -> BB16 has weight 2
-BB15: all outgoing edge weights known, sum is 2
-BB14 -> BB15: target block weight and all other incoming edge weights known, so weight is 2
-BB14: 0 incoming unknown, 0 outgoing unknown
-BB14: all incoming edge weights known, summming...
- BB18 -> BB14 has weight 2
-BB14: all incoming edge weights known, sum is 2
-
-Solver: converged in 1 passes
+BBOPT set, but no profile data available (hr=80004001)
Computing inlinee profile scale:
+ ... no callee profile data, will use non-pgo weight to scale
... call site not profiled, will use non-pgo weight to scale
- call site count 100 callee entry count 2 scale 50
+ call site count 100 callee entry count 100 scale 1
Scaling inlinee blocks
*************** Inline @[000018] Finishing PHASE Profile incorporation In the base we use the PGO data to reverse a branch: @@ -5,10 +5,10 @@ Initial BasicBlocks
BBnum BBid ref try hnd preds weight IBC lp [IL range] [jump] [EH region] [flags]
-----------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000] 1 1 [000..00D) i
-BB02 [0001] 1 0 BB01 1 100 [00D..025)-> BB05 ( cond ) T0 try { keep i try idxlen nullcheck IBC
-BB03 [0014] 1 0 BB02 0.50 50 [00D..00E)-> BB05 ( cond ) T0 i IBC
-BB04 [0015] 1 0 BB03 0.50 50 [00D..00E)-> BB06 ( cond ) T0 i IBC
-BB05 [0016] 3 0 BB02,BB03,BB04 0 0 [00D..00E) T0 i rare hascall gcsafe IBC
+BB02 [0001] 1 0 BB01 1 [00D..025)-> BB05 ( cond ) T0 try { keep i try idxlen nullcheck
+BB03 [0014] 1 0 BB02 0.50 [00D..00E)-> BB05 ( cond ) T0 i
+BB04 [0015] 1 0 BB03 0.50 [00D..00E)-> BB06 ( cond ) T0 i
+BB05 [0016] 3 0 BB02,BB03,BB04 0.50 [00D..00E) T0 i hascall gcsafe
BB06 [0018] 2 0 BB04,BB05 1 [???..???)-> BB08 ( cond ) T0 keep internal idxlen
BB07 [0002] 1 0 BB06 0.50 [025..04C) T0 } i idxlen
BB08 [0028] 2 BB06,BB07 1 [04C..04F)-> BB12 ( cond ) keep i cfb
@@ -30,50 +30,6 @@ BB22 [0022] 1 0 BB20 0 0 [04F..050)
BB23 [0023] 3 0 BB19,BB21,BB22 0 [05B..05C) (finret) H0 } i rare
-----------------------------------------------------------------------------------------------------------------------------------------
-Decided to reverse conditional branch at block BB04 branch to BB06 since it falls into a rarely run block
-fgFindInsertPoint(regionIndex=1, putInTryRegion=true, startBlk=BB02, endBlk=BB08, nearBlk=BB06, jumpBlk=BB00, runRarely=true)
-Relocated rarely run block BB05 by reversing conditional jump at BB04
-Rethreading STMT00034
-Relocated block [BB05..BB05] inserted after BB06
-Block BB05 ended with a BBJ_NONE, Changed to an unconditional jump to BB06
-New Basic Block BB24 [0039] created.
-Setting edge weights for BB06 -> BB24 to [0 .. 3.402823e+38]
-Added an unconditional jump to BB07 after block BB06
-
-After this change in fgReorderBlocks the BB graph is:
------------------------------------------------------------------------------------------------------------------------------------------
-BBnum BBid ref try hnd preds weight IBC lp [IL range] [jump] [EH region] [flags]
------------------------------------------------------------------------------------------------------------------------------------------
-BB01 [0000] 1 1 [000..00D) i
-BB02 [0001] 1 0 BB01 1 100 [00D..025)-> BB05 ( cond ) T0 try { keep i try idxlen nullcheck IBC
-BB03 [0014] 1 0 BB02 0.50 50 [00D..00E)-> BB05 ( cond ) T0 i IBC
-BB04 [0015] 1 0 BB03 0.50 50 [00D..00E)-> BB05 ( cond ) T0 i IBC
-BB06 [0018] 2 0 BB04,BB05 1 [???..???)-> BB08 ( cond ) T0 keep internal idxlen
-BB24 [0039] 1 0 BB06 0.50 [???..???)-> BB07 (always) T0 internal
-BB05 [0016] 3 0 BB02,BB03,BB04 0 0 [00D..00E)-> BB06 (always) T0 i rare hascall gcsafe IBC
-BB07 [0002] 1 0 BB24 0.50 [025..04C) T0 } i idxlen
-BB08 [0028] 2 BB06,BB07 1 [04C..04F)-> BB12 ( cond ) keep i cfb
-BB09 [0029] 1 BB08 0.50 50 [04F..05B)-> BB11 ( cond ) i nullcheck IBC
-BB10 [0031] 1 BB09 0.50 50 [04F..050)-> BB12 (always) i IBC
-BB11 [0032] 1 BB09 0 0 [04F..050) i rare hascall gcsafe IBC
-BB12 [0007] 3 BB08,BB10,BB11 1 [05B..05F)-> BB18 ( cond ) i
-BB13 [0008] 1 BB12 0.50 [05F..06B)-> BB15 ( cond ) i hascall new[]
-BB14 [0038] 1 BB13 0.25 [???..???)-> BB16 (always) i
-BB15 [0037] 1 BB13 0.25 [???..???) i
-BB16 [0035] 2 BB14,BB15 0.50 [06B..07B)-> BB18 ( cond ) i hascall new[]
-BB17 [0009] 1 BB16 0.50 [07B..09B) i hascall gcsafe nullcheck
-BB18 [0010] 3 BB12,BB16,BB17 1 [09B..09D) (return) i
-+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ funclets follow
-BB19 [0004] 1 0 0 [04C..04F)-> BB23 ( cond ) H0 F fault { keep i rare flet
-BB20 [0005] 1 0 BB19 0 0 [04F..05B)-> BB22 ( cond ) H0 i rare nullcheck IBC
-BB21 [0021] 1 0 BB20 0 0 [04F..050)-> BB23 (always) H0 i rare IBC
-BB22 [0022] 1 0 BB20 0 0 [04F..050) H0 i rare hascall gcsafe IBC
-BB23 [0023] 3 0 BB19,BB21,BB22 0 [05B..05C) (finret) H0 } i rare
------------------------------------------------------------------------------------------------------------------------------------------
-
-Decided to straighten unconditional branch at block BB24 branch to BB07 since it is succeeded by a rarely run block
-fgFindInsertPoint(regionIndex=1, putInTryRegion=true, startBlk=BB02, endBlk=BB08, nearBlk=BB07, jumpBlk=BB00, runRarely=true)
-Could not relocate block BB05
Decided to straighten unconditional branch at block BB10 branch to BB12 since it is succeeded by a rarely run block
Relocated rarely run block BB11
Relocated block [BB11..BB11] inserted after BB18
@@ -85,13 +41,12 @@ After this change in fgReorderBlocks the BB graph is:
BBnum BBid ref try hnd preds weight IBC lp [IL range] [jump] [EH region] [flags]
-----------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000] 1 1 [000..00D) i
-BB02 [0001] 1 0 BB01 1 100 [00D..025)-> BB05 ( cond ) T0 try { keep i try idxlen nullcheck IBC
-BB03 [0014] 1 0 BB02 0.50 50 [00D..00E)-> BB05 ( cond ) T0 i IBC
-BB04 [0015] 1 0 BB03 0.50 50 [00D..00E)-> BB05 ( cond ) T0 i IBC
+BB02 [0001] 1 0 BB01 1 [00D..025)-> BB05 ( cond ) T0 try { keep i try idxlen nullcheck
+BB03 [0014] 1 0 BB02 0.50 [00D..00E)-> BB05 ( cond ) T0 i
+BB04 [0015] 1 0 BB03 0.50 [00D..00E)-> BB06 ( cond ) T0 i
+BB05 [0016] 3 0 BB02,BB03,BB04 0.50 [00D..00E) T0 i hascall gcsafe
BB06 [0018] 2 0 BB04,BB05 1 [???..???)-> BB08 ( cond ) T0 keep internal idxlen
-BB24 [0039] 1 0 BB06 0.50 [???..???)-> BB07 (always) T0 internal
-BB05 [0016] 3 0 BB02,BB03,BB04 0 0 [00D..00E)-> BB06 (always) T0 i rare hascall gcsafe IBC
-BB07 [0002] 1 0 BB24 0.50 [025..04C) T0 } i idxlen
+BB07 [0002] 1 0 BB06 0.50 [025..04C) T0 } i idxlen
BB08 [0028] 2 BB06,BB07 1 [04C..04F)-> BB12 ( cond ) keep i cfb
BB09 [0029] 1 BB08 0.50 50 [04F..05B)-> BB11 ( cond ) i nullcheck IBC
BB10 [0031] 1 BB09 0.50 50 [04F..050) i IBC |
I don't see many calls to |
The data we have in the base .mibc is extremely sparse, much too little for us to be basing any decisions off of. We should probably apply a threshold on the dotnet-pgo side when we merge it to StandardOptimizationData.mibc. {
"Method": "[S.P.CoreLib]System.Threading.SpinLock.Enter(bool&)",
"InstrumentationData": [
{
"ILOffset": 0,
"InstrumentationKind": "NumRuns",
"Other": 2
},
{
"ILOffset": 13,
"InstrumentationKind": "EdgeIntCount",
"Other": 46,
"Data": 0
},
{
"ILOffset": 27,
"InstrumentationKind": "EdgeIntCount",
"Other": 46,
"Data": 0
},
{
"ILOffset": 27,
"InstrumentationKind": "EdgeIntCount",
"Other": 54,
"Data": 2
},
{
"ILOffset": 54,
"InstrumentationKind": "EdgeIntCount",
"Other": 0,
"Data": 2
}
]
}, Considering that we do get a good performance gain here though we should probably think about how we can get it via a synthetic profile. |
Yeah, that's what I was doing. I have two enlistments, both built clean: c9f80fd (base) and a38b50c (diff) -- these are the endpoints from the original report. a38b50c Remove some unnecessary fixed blocks (#71317) -- (my diff) Comparing codegen, it looks like I'm on a device with LSE and you're not? |
In both my base and diff we find profile data for
|
Yes, this is from a Raspberry Pi 400, it does not have LSE. It is pretty odd that we are ending up with different profile data, let's try to compare the .mibc files from our builds... |
Seems like I'm looking at windows, Jakob at ubuntu. The regression was on ubuntu. |
Now running locally on ubuntu/ampere. I can repro the slowdown with my base/diff builds (per above). BenchmarkDotNet=v0.13.1.1786-nightly, OS=ubuntu 22.04 PowerPlanMode=00000000-0000-0000-0000-000000000000 IterationTime=250.0000 ms MaxIterationCount=20
Looking at dumps, they look similar to what @jakobbotsch sees on the Rpi4, there is no pgo data for 'SpinLock:Enter`
and this leads to code layout diffs. We compare a bit more favorably to 6.0 though the numbers for 6.0 bounce around quite a bit. BenchmarkDotNet=v0.13.1.1786-nightly, OS=ubuntu 22.04 PowerPlanMode=00000000-0000-0000-0000-000000000000 IterationTime=250.0000 ms MaxIterationCount=20
|
Ampere codegen for the various rr.ampere.diff.dasm.txt There is possibly a PGO update coming into 7.0 that might fix this, if not we are just going to have to live with this. As noted above, vs 6.0 we don't look quite as bad. |
@AndyAyersMS Has the PGO update come through, and/or should we go ahead and close this? |
We had a PGO update on 8/17 just after the RC1 snap that got backported: #73973 But nothing much seems to have changed for these two tests (note the lab is measuring I don't think we can do anything about this regression for .NET 7. But the underlying issue of very thin PGO data remains, so we should move this to 8.0. Also, looking a bit more broadly...
@dakersnar I still see more or less all the tests here as regressing -- did "solved" mean that these regressions were deemed necessary somehow? |
@AndyAyersMS Taking a second look I think I was mistaken. I was referring to the larger July 3rd regression, but this issue is actually referring to the smaller regression on June 27th, which you are correct has not been solved. |
Thank you, @AndyAyersMS and @dakersnar. Per Andy's comment above then, we will accept this regression since we are still in good shape for 6.0 vs. 7.0. |
Run Information
Regressions in System.Text.Json.Tests.Perf_Deep
Test Report
Repro
Payloads
Baseline
Compare
Histogram
System.Text.Json.Tests.Perf_Deep.WriteDeepUtf16(Formatted: False, SkipValidation: True)
Description of detection logic
Description of detection logic
Description of detection logic
Docs
Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository
Regressions in System.Text.Json.Tests.Perf_Basic
Test Report
Repro
Payloads
Baseline
Compare
Histogram
System.Text.Json.Tests.Perf_Basic.WriteBasicUtf16(Formatted: False, SkipValidation: True, DataSize: 100000)
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Docs
Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository
Run Information
Regressions in System.Buffers.Tests.RentReturnArrayPoolTests<Object>
Test Report
Repro
Payloads
Baseline
Compare
Histogram
System.Buffers.Tests.RentReturnArrayPoolTests<Object>.MultipleSerial(RentalSize: 4096, ManipulateArray: False, Async: False, UseSharedPool: False)
Description of detection logic
Description of detection logic
Docs
Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository
Run Information
Regressions in System.Buffers.Text.Tests.Utf8FormatterTests
Test Report
Repro
Payloads
Baseline
Compare
Histogram
System.Buffers.Text.Tests.Utf8FormatterTests.FormatterInt32(value: 12345)
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Description of detection logic
Docs
Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository
Run Information
Regressions in System.Collections.Concurrent.Count<String>
Test Report
Repro
Payloads
Baseline
Compare
Histogram
System.Collections.Concurrent.Count<String>.Queue(Size: 512)
Description of detection logic
Description of detection logic
Docs
Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository
Run Information
Regressions in System.Buffers.Tests.ReadOnlySequenceTests<Char>
Test Report
Repro
Payloads
Baseline
Compare
Histogram
System.Buffers.Tests.ReadOnlySequenceTests<Char>.FirstSpanTenSegments
Description of detection logic
Docs
Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository
The text was updated successfully, but these errors were encountered: