andrewlock
commented
2 months ago Execution-Time Benchmarks Report :stopwatch:
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:
- Welch test with statistical test for significance of 5%
- Only results indicating a difference greater than 5% and 5 ms are considered.
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 (6041) - mean (69ms) : 68, 71
. : milestone, 69,
master - mean (70ms) : 67, 73
. : milestone, 70,
section CallTarget+Inlining+NGEN
This PR (6041) - mean (1,108ms) : 1084, 1133
. : milestone, 1108,
master - mean (1,109ms) : 1084, 1133
. : milestone, 1109,
gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6041) - mean (109ms) : 106, 112
. : milestone, 109,
master - mean (109ms) : 106, 111
. : milestone, 109,
section CallTarget+Inlining+NGEN
This PR (6041) - mean (770ms) : 754, 786
. : milestone, 770,
master - mean (769ms) : 749, 790
. : milestone, 769,
gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6041) - mean (92ms) : 89, 95
. : milestone, 92,
master - mean (92ms) : 89, 94
. : milestone, 92,
section CallTarget+Inlining+NGEN
This PR (6041) - mean (721ms) : 706, 736
. : milestone, 721,
master - mean (727ms) : 707, 746
. : milestone, 727,
gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.6.2)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6041) - mean (191ms) : 187, 195
. : milestone, 191,
master - mean (192ms) : 188, 196
. : milestone, 192,
section CallTarget+Inlining+NGEN
This PR (6041) - mean (1,205ms) : 1178, 1231
. : milestone, 1205,
master - mean (1,203ms) : 1180, 1226
. : milestone, 1203,
gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6041) - mean (276ms) : 272, 280
. : milestone, 276,
master - mean (276ms) : 272, 280
. : milestone, 276,
section CallTarget+Inlining+NGEN
This PR (6041) - mean (946ms) : 929, 962
. : milestone, 946,
master - mean (946ms) : 925, 968
. : milestone, 946,
gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6041) - mean (265ms) : 260, 270
. : milestone, 265,
master - mean (265ms) : 261, 269
. : milestone, 265,
section CallTarget+Inlining+NGEN
This PR (6041) - mean (927ms) : 908, 945
. : milestone, 927,
master - mean (930ms) : 912, 948
. : milestone, 930,
datadog-ddstaging[bot]
bouwkast
agocs
github-actions[bot]
Summary of changes
I've updated the Lambda extension so it is capable of returning a 128 bit trace ID when a tracer calls the
/lambda/start-invocationendpoint in this PRAs per the RFC, the
This change modifies the function that calls
/lambda/start-invocation, allowing it to pick out the upper 64 bits of the trace ID and set the resulting 128-bit trace ID in the extracted context.Reason for change
The Lambda Extension may now return a 128 bit trace ID when a Step Function invokes a Lambda Function.
Implementation details
I rewrote LambdaCommon's
CreatePlaceholderScopeso it usesSpanContextPropagator.Instance.Extractrather than extracting trace context elements one by one.Test coverage
Added a unit test for 128 bit trace IDs. Fixed existing unit tests so they pass a dictionary of headers to CreatePlaceholderScope. Removed a unit test that only passes SamplingPriority, since a distributed trace with only a sampling priority is hardly a distributed trace at all.
Other details
Backported to 2.x in #6181