Remove usage of ArrayPool<T> from ChunkedEncodingReadStream
#5247
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
andrewlock
added
the
area:tracer
Datadog ReportBranch report: ✅ 0 Failed, 325245 Passed, 1508 Skipped, 41m 40.41s Wall Time ⌛ Performance Regressions vs Default Branch (1)
|
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing the following branches/commits: Execution-time benchmarks measure the whole time it takes to execute a program. And are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are shown in red. The following thresholds were used for comparing the execution times:
Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard. Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph). gantt
title Execution time (ms) FakeDbCommand (.NET Framework 4.6.2)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (5247) - mean (74ms) : 65, 82
. : milestone, 74,
master - mean (72ms) : 65, 78
. : milestone, 72,
section CallTarget+Inlining+NGEN
This PR (5247) - mean (983ms) : 961, 1005
. : milestone, 983,
master - mean (986ms) : 961, 1011
. : milestone, 986,
gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (5247) - mean (111ms) : 108, 114
. : milestone, 111,
master - mean (110ms) : 107, 113
. : milestone, 110,
section CallTarget+Inlining+NGEN
This PR (5247) - mean (719ms) : 693, 745
. : milestone, 719,
master - mean (717ms) : 689, 745
. : milestone, 717,
gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (5247) - mean (95ms) : 92, 98
. : milestone, 95,
master - mean (93ms) : 90, 96
. : milestone, 93,
section CallTarget+Inlining+NGEN
This PR (5247) - mean (670ms) : 644, 697
. : milestone, 670,
master - mean (664ms) : 641, 688
. : milestone, 664,
gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.6.2)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (5247) - mean (187ms) : 184, 191
. : milestone, 187,
master - mean (188ms) : 183, 193
. : milestone, 188,
section CallTarget+Inlining+NGEN
This PR (5247) - mean (1,057ms) : 1031, 1082
. : milestone, 1057,
master - mean (1,060ms) : 1035, 1085
. : milestone, 1060,
gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (5247) - mean (270ms) : 265, 276
. : milestone, 270,
master - mean (268ms) : 262, 274
. : milestone, 268,
section CallTarget+Inlining+NGEN
This PR (5247) - mean (1,059ms) : 1029, 1088
. : milestone, 1059,
master - mean (1,055ms) : 1031, 1079
. : milestone, 1055,
gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (5247) - mean (259ms) : 254, 265
. : milestone, 259,
master - mean (257ms) : 252, 262
. : milestone, 257,
section CallTarget+Inlining+NGEN
This PR (5247) - mean (1,001ms) : 972, 1029
. : milestone, 1001,
master - mean (995ms) : 960, 1030
. : milestone, 995,
|
kevingosse
approved these changes
Feb 28, 2024
andrewlock
force-pushed
the
andrew/remove-array-pool
branch
from
aa4a106
to
c062c54
Compare
Throughput/Crank Report:zap:Throughput results for AspNetCoreSimpleController comparing the following branches/commits: Cases where throughput results for the PR are worse than latest master (5% drop or greater), results are shown in red. Note that these results are based on a single point-in-time result for each branch. For full results, see one of the many, many dashboards! gantt
title Throughput Linux x64 (Total requests)
dateFormat X
axisFormat %s
section Baseline
This PR (5247) (11.394M) : 0, 11394136
master (11.427M) : 0, 11427055
benchmarks/2.9.0 (11.031M) : 0, 11030962
section Automatic
This PR (5247) (7.619M) : 0, 7619439
master (7.902M) : 0, 7902413
benchmarks/2.9.0 (8.233M) : 0, 8232945
section Trace stats
This PR (5247) (8.114M) : 0, 8113868
master (8.178M) : 0, 8178196
section Manual
This PR (5247) (9.606M) : 0, 9606003
master (9.839M) : 0, 9839129
section Manual + Automatic
This PR (5247) (7.227M) : 0, 7226584
master (7.499M) : 0, 7498984
section Version Conflict
This PR (5247) (6.541M) : 0, 6540910
master (6.572M) : 0, 6571888
gantt
title Throughput Linux arm64 (Total requests)
dateFormat X
axisFormat %s
section Baseline
This PR (5247) (9.670M) : 0, 9670235
master (9.632M) : 0, 9631695
benchmarks/2.9.0 (9.465M) : 0, 9464836
section Automatic
This PR (5247) (6.701M) : 0, 6701186
master (6.626M) : 0, 6625633
section Trace stats
This PR (5247) (6.831M) : 0, 6831361
master (6.721M) : 0, 6721457
section Manual
This PR (5247) (8.111M) : 0, 8110744
master (8.178M) : 0, 8178488
section Manual + Automatic
This PR (5247) (6.089M) : 0, 6088850
master (6.346M) : 0, 6345857
section Version Conflict
This PR (5247) (5.644M) : 0, 5644466
master (5.724M) : 0, 5724471
gantt
title Throughput Windows x64 (Total requests)
dateFormat X
axisFormat %s
section Baseline
This PR (5247) (10.157M) : 0, 10157379
master (9.722M) : 0, 9721673
benchmarks/2.9.0 (10.140M) : 0, 10140137
section Automatic
This PR (5247) (7.166M) : 0, 7165720
master (6.862M) : 0, 6862026
benchmarks/2.9.0 (7.489M) : 0, 7488546
section Trace stats
This PR (5247) (7.594M) : 0, 7594475
master (7.178M) : 0, 7177723
section Manual
This PR (5247) (7.931M) : crit ,0, 7930959
master (8.499M) : 0, 8498972
section Manual + Automatic
This PR (5247) (6.202M) : crit ,0, 6201855
master (6.679M) : 0, 6678812
section Version Conflict
This PR (5247) (5.294M) : crit ,0, 5293967
master (6.136M) : 0, 6135785
gantt
title Throughput Linux x64 (ASM) (Total requests)
dateFormat X
axisFormat %s
section Baseline
master (7.487M) : 0, 7487267
benchmarks/2.9.0 (7.871M) : 0, 7870513
section No attack
master (1.832M) : 0, 1832296
benchmarks/2.9.0 (3.232M) : 0, 3232114
section Attack
master (1.466M) : 0, 1465863
benchmarks/2.9.0 (2.539M) : 0, 2539351
section Blocking
master (3.203M) : 0, 3203470
section IAST default
master (6.584M) : 0, 6583631
section IAST full
master (5.755M) : 0, 5754986
section Base vuln
master (0.995M) : 0, 995004
section IAST vuln
master (0.873M) : 0, 873003
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of changes
Removes the
ArrayPool<>usage fromChunkedEncodingReadStreamReason for change
The existing code (
DatadogHttpClientet al.) does not dispose theStreamContent, which means we would be leaking a largeArrayPool<byte>array with every request 😱Implementation details
Just new-up a new array. This is annoying from a perf PoV, but it's safe.
This code-path is only hit when the agent sends chunked-responses, and that's only when there's a lot of data to return, so it's not like we'll always be making these allocations.
Test coverage
Functionally unchanged, so covered by existing tests
Other details
Obviously the alternative would be to dispose of the
Streamproperly, but that would require wider refactoring changes to all our abstractions which is more risk than I want to take on.Also, our HTTP APIs here are already pretty un-performant (we're always buffering responses in memory and wrapping a
MemoryStreamaround them for example), so it doesn't seem worth the risk to optimize this one small part. There are lots of other places that would benefit fromArrayPool<T>usages if we want to take that approach, and in other paths we will have more visibility if we introduce memory leaks due to not returning to the pool correctly.