Vendor in Microsoft.OpenApi #6461
Merged
+14,550
−10
Conversation
This file contains hidden or 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
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 (6461) - mean (69ms) : 66, 72
. : milestone, 69,
master - mean (69ms) : 66, 71
. : milestone, 69,
section CallTarget+Inlining+NGEN
This PR (6461) - mean (983ms) : 954, 1011
. : milestone, 983,
master - mean (981ms) : 957, 1004
. : milestone, 981,
gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6461) - mean (108ms) : 106, 110
. : milestone, 108,
master - mean (108ms) : 105, 111
. : milestone, 108,
section CallTarget+Inlining+NGEN
This PR (6461) - mean (679ms) : 664, 694
. : milestone, 679,
master - mean (678ms) : 665, 692
. : milestone, 678,
gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6461) - mean (91ms) : 89, 93
. : milestone, 91,
master - mean (92ms) : 90, 93
. : milestone, 92,
section CallTarget+Inlining+NGEN
This PR (6461) - mean (635ms) : 619, 650
. : milestone, 635,
master - mean (636ms) : 620, 652
. : milestone, 636,
gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.6.2)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6461) - mean (194ms) : 189, 198
. : milestone, 194,
master - mean (194ms) : 189, 198
. : milestone, 194,
section CallTarget+Inlining+NGEN
This PR (6461) - mean (1,104ms) : 1072, 1135
. : milestone, 1104,
master - mean (1,103ms) : 1076, 1130
. : milestone, 1103,
gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6461) - mean (278ms) : 275, 281
. : milestone, 278,
master - mean (280ms) : 276, 284
. : milestone, 280,
section CallTarget+Inlining+NGEN
This PR (6461) - mean (873ms) : 841, 904
. : milestone, 873,
master - mean (873ms) : 849, 897
. : milestone, 873,
gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6461) - mean (267ms) : 263, 271
. : milestone, 267,
master - mean (269ms) : 264, 273
. : milestone, 269,
section CallTarget+Inlining+NGEN
This PR (6461) - mean (848ms) : 827, 870
. : milestone, 848,
master - mean (856ms) : 821, 890
. : milestone, 856,
|
Throughput/Crank Report ⚡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 (6461) (11.209M) : 0, 11209227
master (11.152M) : 0, 11152447
benchmarks/2.9.0 (11.144M) : 0, 11143547
section Automatic
This PR (6461) (7.426M) : 0, 7425806
master (7.354M) : 0, 7353844
benchmarks/2.9.0 (7.982M) : 0, 7981525
section Trace stats
master (7.558M) : 0, 7558154
section Manual
master (11.199M) : 0, 11198717
section Manual + Automatic
This PR (6461) (6.794M) : 0, 6793605
master (6.716M) : 0, 6715949
section DD_TRACE_ENABLED=0
master (10.213M) : 0, 10213385
gantt
title Throughput Linux arm64 (Total requests)
dateFormat X
axisFormat %s
section Baseline
This PR (6461) (9.654M) : 0, 9653861
benchmarks/2.9.0 (9.621M) : 0, 9621397
section Automatic
This PR (6461) (6.367M) : 0, 6367403
section Manual + Automatic
This PR (6461) (6.013M) : 0, 6013497
gantt
title Throughput Windows x64 (Total requests)
dateFormat X
axisFormat %s
section Baseline
This PR (6461) (10.361M) : 0, 10361171
master (10.200M) : 0, 10200189
section Automatic
This PR (6461) (6.886M) : 0, 6885640
master (6.736M) : 0, 6735703
section Trace stats
master (7.380M) : 0, 7380123
section Manual
master (10.350M) : 0, 10350365
section Manual + Automatic
This PR (6461) (6.593M) : 0, 6592644
master (6.235M) : 0, 6234677
section DD_TRACE_ENABLED=0
master (9.495M) : 0, 9495186
|
Benchmarks Report for tracer 🐌Benchmarks for #6461 compared to master:
The following thresholds were used for comparing the benchmark speeds:
Allocation changes below 0.5% are ignored. Benchmark detailsBenchmarks.Trace.ActivityBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AgentWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AspNetCoreBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.DbCommandBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ElasticsearchBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.GraphQLBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.HttpClientBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ILoggerBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.Log4netBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.NLogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.RedisBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SerilogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SpanBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.TraceAnnotationsBenchmark - Same speed ✔️ Same allocations ✔️Raw results
|
Datadog ReportBranch report: ✅ 0 Failed, 239484 Passed, 2118 Skipped, 19h 25m 12.7s Total Time |
vandonr
force-pushed
the
vandonr/vendored
branch
from
17992fc to
43a3d3d
Compare
andrewlock
reviewed
Dec 31, 2024
There was a problem hiding this comment.
I doubt we want to vendor in the SRResource.resx files? 🤔
There was a problem hiding this comment.
I think we do, because it's referenced everywhere, in error messages for instance
There was a problem hiding this comment.
The designer file is referenced (as that has the c# code) but I don't think we need the resx files themselves
There was a problem hiding this comment.
Yes you are right, I don't think the resx file is needed at compile time, however it contains the values for all the error messages. I guess this means if there is an error, then there will be an error within the error when trying to get the error message. Maybe it's OK ?
There was a problem hiding this comment.
Urgh, you're right, for some reason I thought the designer.cs code included hard-coded versions of the resx. That said, is this actually being used anyway 🤔 IIRC you have to embed the resx file for this to work. Frankly I'd be inclined to do some munging and hardcode it to avoid the bloat.
if there is an error, then there will be an error within the error
Yeah the more important point though is yes, if this happens, Bad Things™ will likely happen, so we need to make sure it's "working" correctly either way, whether that's with hard coding/stripping it out/Or embedding (note that we don't embed any other resx files, I'm not massively inclined to start, personally 😄)
There was a problem hiding this comment.
okay, inlining is not too easy to do using our current tooling though, because the callback to apply changes to files only looks at files one by one...
tracer/src/Datadog.Trace/Vendors/Microsoft.OpenApi/Extensions/OpenApiTypeMapper.cs
Outdated
Show resolved
Hide resolved
tracer/src/Datadog.Trace/Vendors/Microsoft.OpenApi/Services/OpenApiUrlTreeNode.cs
Outdated
Show resolved
Hide resolved
tracer/src/Datadog.Tracer.Native/Generated/generated_calltargets.g.cpp
Outdated
Show resolved
Hide resolved
andrewlock
reviewed
Dec 31, 2024
|
no we probably don't need everything. I'm only going to use it to build the object representing the schema, and then serialize it to json. In Java, it was reimplemented manually. That's an option too, but I wanted to use existing code as much as possible. |
|
it's relatively hard to strip it by entire files. I did my best, but stripping more would require editing the code to remove references elsewhere, which would be quite a pain (like, there is a visitor referencing every model, and OpenApiDocument has a field for each document type for instance, removing a single Model that we don't use would require editing those two). If it's still too big, I can write the objects and json serialization myself too, but that's risks of bugs && time spent not doing something else. |
andrewlock
approved these changes
Jan 14, 2025
kevingosse
approved these changes
Jan 14, 2025
chojomok
pushed a commit
that referenced
this pull request
Jul 15, 2025
## Summary of changes added the code of Microsoft.OpenApi to the tracer, removed/changed the parts that require more recent versions of the language/fwk than we have, and updated generated files. ## Reason for change It's going to be needed for the protobuf instrumentation in #6166, and I'm doing it in a separate PR to limit the size of the diff in the actual change. ## Implementation details @bouwkast ran the vendoring tool to add the files, since it's not working on Mac apparently ## Test coverage ## Other details When looking at the size of artefacts published on the CI, it looks like this is increasing the size of the dll by ~180KiB <!--⚠️ Note: where possible, please obtain 2 approvals prior to merging. Unless CODEOWNERS specifies otherwise, for external teams it is typically best to have one review from a team member, and one review from apm-dotnet. Trivial changes do not require 2 reviews. --> --------- Co-authored-by: Steven Bouwkamp <[email protected]>
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
added the code of Microsoft.OpenApi to the tracer, removed/changed the parts that require more recent versions of the language/fwk than we have, and updated generated files.
Reason for change
It's going to be needed for the protobuf instrumentation in #6166, and I'm doing it in a separate PR to limit the size of the diff in the actual change.
Implementation details
@bouwkast ran the vendoring tool to add the files, since it's not working on Mac apparently
Test coverage
Other details
When looking at the size of artefacts published on the CI, it looks like this is increasing the size of the dll by ~180KiB