Skip to content

[Config] Register all native configuration variables (3/3)#8733

Merged
bm1549 merged 19 commits into
masterfrom
brian.marks/native-config-scope-pr3
Jun 18, 2026
Merged

[Config] Register all native configuration variables (3/3)#8733
bm1549 merged 19 commits into
masterfrom
brian.marks/native-config-scope-pr3

Conversation

@bm1549

@bm1549 bm1549 commented Jun 2, 2026

Copy link
Copy Markdown
Contributor

Summary of changes

Registers previously unregistered native-only DD_* configuration variables and upgrades existing entries that are also read by native code to scope: managed, native. Adds a standalone validator tool, run by a dedicated GitHub Action, that enforces complete native coverage.

Stack:

  • PR 1 (merged): scope: managed on all existing entries
  • PR 2 (merged): scope infrastructure
  • PR 3 (this): all native config variables + the coverage validator

Reason for change

Many native-consumed DD_* variables were absent from supported-configurations.yaml, making the registry an incomplete picture of the tracer's configuration surface. The validator added here fails CI if a new native variable is read without a registry entry.

Implementation details

Registry entries — native-only keys get scope: native; keys read by both native and managed code are upgraded to scope: managed, native (DD_TRACE_ENABLED, DD_ENV, DD_SERVICE, DD_APPSEC_ENABLED, DD_INJECTION_ENABLED, etc.). Coverage spans tracer native (DD_CLR_*, DD_LOADER_*), the shared loader (DD_CRASHTRACKING_*, DD_TELEMETRY_FORWARDER_PATH), DD_INTERNAL_*, and the Continuous Profiler (DD_PROFILING_*).

Native coverage validatortracer/src/Datadog.Trace.Tools.NativeConfigValidator, a standalone tool run by the dedicated validate_native_configurations GitHub Action. It scans tracer/src/Datadog.Tracer.Native, shared/src, and profiler/src for DD_*/_DD_* literals and asserts each is registered with native scope. It reuses the source generator's YamlReader (source-linked) so the validator and the ConfigurationKeys generator cannot drift. A failure means "update the registry", so it lives in its own workflow rather than the source-generator verification job.

Test coverage

The validator runs in its own GitHub Action on PRs touching the registry or native source, and passes against the current registry (123 native variables covered).

Other details

The validate_supported_configurations_v2_local_file CI check requires every entry in this file to be registered in the central Configuration Registry. The new native-only entries are not yet there. I will register them before merging.

@bm1549 bm1549 added the AI Generated Largely based on code generated by an AI or LLM. This label is the same across all dd-trace-* repos label Jun 2, 2026
@datadog-prod-us1-3

This comment has been minimized.

@bm1549
bm1549 force-pushed the brian.marks/native-config-scope-pr2 branch from a74d141 to 2fe83b1 Compare June 2, 2026 17:22
@bm1549
bm1549 force-pushed the brian.marks/native-config-scope-pr3 branch from 70f1b76 to 867e7b9 Compare June 2, 2026 17:23
@bm1549
bm1549 force-pushed the brian.marks/native-config-scope-pr2 branch from 2fe83b1 to ace5613 Compare June 2, 2026 17:24
@bm1549
bm1549 force-pushed the brian.marks/native-config-scope-pr3 branch from 867e7b9 to 843253b Compare June 2, 2026 17:24
@bm1549
bm1549 requested a review from anna-git June 2, 2026 17:42
@pr-commenter

pr-commenter Bot commented Jun 2, 2026

Copy link
Copy Markdown

Benchmarks

Benchmark execution time: 2026-06-17 14:39:19

Comparing candidate commit f7a56ec in PR branch brian.marks/native-config-scope-pr3 with baseline commit 2d3de8b in branch master.

📊 Benchmarking dashboard

Found 0 performance improvements and 1 performance regressions! Performance is the same for 71 metrics, 0 unstable metrics, 63 known flaky benchmarks, 63 flaky benchmarks without significant changes.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:Benchmarks.Trace.HttpClientBenchmark.SendAsync net472

  • 🟥 throughput [-4845.661op/s; -4574.645op/s] or [-5.532%; -5.222%]

Known flaky benchmarks

These benchmarks are marked as flaky and will not trigger a failure. Modify FLAKY_BENCHMARKS_REGEX to control which benchmarks are marked as flaky.

scenario:Benchmarks.Trace.ActivityBenchmark.StartStopWithChild net472

  • 🟥 throughput [-6437.941op/s; -6003.657op/s] or [-7.633%; -7.119%]

scenario:Benchmarks.Trace.ActivityBenchmark.StartStopWithChild netcoreapp3.1

  • 🟥 throughput [-9071.968op/s; -7734.282op/s] or [-9.224%; -7.864%]

scenario:Benchmarks.Trace.AgentWriterBenchmark.WriteAndFlushEnrichedTraces net472

  • 🟥 execution_time [+300.837ms; +307.362ms] or [+149.286%; +152.524%]
  • 🟥 throughput [-45.004op/s; -41.362op/s] or [-8.097%; -7.442%]

scenario:Benchmarks.Trace.AgentWriterBenchmark.WriteAndFlushEnrichedTraces net6.0

  • 🟥 execution_time [+381.811ms; +385.572ms] or [+301.654%; +304.626%]
  • 🟩 throughput [+85.228op/s; +91.382op/s] or [+11.237%; +12.048%]

scenario:Benchmarks.Trace.AgentWriterBenchmark.WriteAndFlushEnrichedTraces netcoreapp3.1

  • 🟥 execution_time [+393.632ms; +395.748ms] or [+348.350%; +350.222%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.AllCycleMoreComplexBody net472

  • 🟥 allocated_mem [+1.308KB; +1.308KB] or [+27.528%; +27.540%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.AllCycleMoreComplexBody net6.0

  • 🟥 allocated_mem [+471 bytes; +472 bytes] or [+9.976%; +9.987%]
  • 🟩 execution_time [-15.638ms; -11.396ms] or [-7.303%; -5.322%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.AllCycleMoreComplexBody netcoreapp3.1

  • 🟥 allocated_mem [+1.272KB; +1.272KB] or [+27.500%; +27.510%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.AllCycleSimpleBody net472

  • 🟥 allocated_mem [+1.307KB; +1.307KB] or [+105.743%; +105.758%]
  • 🟥 throughput [-268734.260op/s; -265122.129op/s] or [-27.439%; -27.070%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.AllCycleSimpleBody net6.0

  • 🟥 allocated_mem [+471 bytes; +472 bytes] or [+38.557%; +38.566%]
  • 🟩 execution_time [-25.789ms; -20.923ms] or [-11.501%; -9.331%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.AllCycleSimpleBody netcoreapp3.1

  • 🟥 allocated_mem [+1.272KB; +1.272KB] or [+105.288%; +105.304%]
  • 🟥 throughput [-176941.360op/s; -159423.201op/s] or [-25.423%; -22.906%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorMoreComplexBody net6.0

  • 🟩 throughput [+8908.760op/s; +11838.699op/s] or [+5.668%; +7.533%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorMoreComplexBody netcoreapp3.1

  • 🟩 throughput [+8543.289op/s; +11347.491op/s] or [+6.806%; +9.040%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorSimpleBody net6.0

  • 🟩 throughput [+343685.473op/s; +415535.686op/s] or [+11.460%; +13.856%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorSimpleBody netcoreapp3.1

  • 🟩 execution_time [-19.175ms; -14.832ms] or [-8.839%; -6.837%]
  • 🟩 throughput [+136345.240op/s; +189671.699op/s] or [+5.412%; +7.529%]

scenario:Benchmarks.Trace.Asm.AppSecEncoderBenchmark.EncodeArgs net472

  • 🟥 execution_time [+299.952ms; +300.659ms] or [+149.876%; +150.229%]

scenario:Benchmarks.Trace.Asm.AppSecEncoderBenchmark.EncodeArgs net6.0

  • 🟥 execution_time [+299.389ms; +302.631ms] or [+150.983%; +152.617%]

scenario:Benchmarks.Trace.Asm.AppSecEncoderBenchmark.EncodeArgs netcoreapp3.1

  • 🟥 execution_time [+299.907ms; +302.894ms] or [+151.070%; +152.574%]

scenario:Benchmarks.Trace.Asm.AppSecEncoderBenchmark.EncodeLegacyArgs net472

  • 🟥 execution_time [+297.602ms; +298.623ms] or [+146.170%; +146.672%]

scenario:Benchmarks.Trace.Asm.AppSecEncoderBenchmark.EncodeLegacyArgs net6.0

  • 🟥 execution_time [+296.570ms; +299.010ms] or [+144.982%; +146.175%]

scenario:Benchmarks.Trace.Asm.AppSecEncoderBenchmark.EncodeLegacyArgs netcoreapp3.1

  • 🟥 execution_time [+299.350ms; +300.941ms] or [+149.615%; +150.410%]

scenario:Benchmarks.Trace.Asm.AppSecWafBenchmark.RunWafRealisticBenchmarkWithAttack net6.0

  • 🟥 execution_time [+21.949µs; +45.532µs] or [+7.007%; +14.536%]
  • 🟥 throughput [-424.856op/s; -226.377op/s] or [-13.244%; -7.057%]

scenario:Benchmarks.Trace.AspNetCoreBenchmark.SendRequest net472

  • 🟥 execution_time [+299.971ms; +300.763ms] or [+149.716%; +150.112%]

scenario:Benchmarks.Trace.AspNetCoreBenchmark.SendRequest net6.0

  • unstable execution_time [+414.270ms; +425.408ms] or [+450.122%; +462.223%]
  • 🟩 throughput [+688.442op/s; +872.921op/s] or [+5.657%; +7.173%]

scenario:Benchmarks.Trace.AspNetCoreBenchmark.SendRequest netcoreapp3.1

  • unstable execution_time [+294.022ms; +347.079ms] or [+223.248%; +263.534%]

scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces net472

  • 🟥 allocated_mem [+2.885KB; +2.891KB] or [+5.126%; +5.136%]
  • unstable execution_time [+301.911ms; +369.129ms] or [+138.816%; +169.722%]
  • 🟥 throughput [-609.774op/s; -558.224op/s] or [-55.251%; -50.581%]

scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces net6.0

  • unstable execution_time [+144.454ms; +290.215ms] or [+61.560%; +123.677%]
  • 🟥 throughput [-670.997op/s; -587.448op/s] or [-44.756%; -39.183%]

scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces netcoreapp3.1

  • 🟥 execution_time [+347.832ms; +358.881ms] or [+208.044%; +214.653%]
  • 🟥 throughput [-438.792op/s; -404.049op/s] or [-30.552%; -28.133%]

scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSlice net472

  • 🟩 execution_time [-118.111µs; -109.090µs] or [-5.944%; -5.490%]
  • 🟩 throughput [+29.282op/s; +31.810op/s] or [+5.819%; +6.321%]

scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSliceWithPool netcoreapp3.1

  • unstable throughput [+4.452op/s; +121.552op/s] or [+0.831%; +22.689%]

scenario:Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearch net472

  • 🟥 execution_time [+301.635ms; +303.926ms] or [+151.898%; +153.051%]

scenario:Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearch net6.0

  • unstable execution_time [+302.723ms; +327.009ms] or [+151.695%; +163.865%]

scenario:Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearch netcoreapp3.1

  • 🟥 execution_time [+299.742ms; +315.926ms] or [+150.578%; +158.708%]

scenario:Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearchAsync net472

  • 🟥 execution_time [+302.180ms; +304.499ms] or [+151.744%; +152.909%]

scenario:Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearchAsync net6.0

  • 🟥 execution_time [+299.365ms; +301.339ms] or [+148.023%; +148.998%]

scenario:Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearchAsync netcoreapp3.1

  • 🟥 execution_time [+302.387ms; +305.828ms] or [+153.263%; +155.007%]

scenario:Benchmarks.Trace.GraphQLBenchmark.ExecuteAsync net472

  • 🟥 execution_time [+301.140ms; +303.939ms] or [+151.145%; +152.550%]

scenario:Benchmarks.Trace.GraphQLBenchmark.ExecuteAsync net6.0

  • 🟥 execution_time [+301.530ms; +304.566ms] or [+150.285%; +151.798%]
  • 🟩 throughput [+27889.172op/s; +40410.513op/s] or [+5.538%; +8.024%]

scenario:Benchmarks.Trace.GraphQLBenchmark.ExecuteAsync netcoreapp3.1

  • 🟥 execution_time [+302.126ms; +305.429ms] or [+150.305%; +151.948%]

scenario:Benchmarks.Trace.ILoggerBenchmark.EnrichedLog net6.0

  • 🟩 execution_time [-15.968ms; -12.309ms] or [-7.425%; -5.724%]

scenario:Benchmarks.Trace.ILoggerBenchmark.EnrichedLog netcoreapp3.1

  • 🟩 throughput [+14341.035op/s; +20031.990op/s] or [+5.235%; +7.312%]

scenario:Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatAspectBenchmark net472

  • unstable execution_time [+10.286µs; +54.880µs] or [+2.541%; +13.556%]

scenario:Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatAspectBenchmark net6.0

  • 🟩 allocated_mem [-18.721KB; -18.697KB] or [-6.829%; -6.820%]
  • unstable execution_time [-35.917µs; +23.136µs] or [-7.099%; +4.573%]
  • unstable throughput [-76.529op/s; +126.927op/s] or [-3.819%; +6.334%]

scenario:Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatAspectBenchmark netcoreapp3.1

  • unstable execution_time [-50.717µs; +10.196µs] or [-8.789%; +1.767%]

scenario:Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatBenchmark net6.0

  • unstable execution_time [+6.723µs; +11.079µs] or [+15.892%; +26.188%]
  • 🟥 throughput [-5003.226op/s; -3145.636op/s] or [-21.062%; -13.242%]

scenario:Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatBenchmark netcoreapp3.1

  • unstable execution_time [-15.104µs; -7.542µs] or [-23.434%; -11.701%]
  • unstable throughput [+1942.502op/s; +3599.780op/s] or [+11.918%; +22.086%]

scenario:Benchmarks.Trace.Log4netBenchmark.EnrichedLog net472

  • 🟥 execution_time [+302.341ms; +303.513ms] or [+152.820%; +153.412%]

scenario:Benchmarks.Trace.Log4netBenchmark.EnrichedLog net6.0

  • 🟥 execution_time [+303.555ms; +307.226ms] or [+154.508%; +156.377%]

scenario:Benchmarks.Trace.Log4netBenchmark.EnrichedLog netcoreapp3.1

  • 🟥 execution_time [+302.642ms; +306.022ms] or [+151.510%; +153.202%]

scenario:Benchmarks.Trace.RedisBenchmark.SendReceive net6.0

  • 🟩 throughput [+31825.091op/s; +35111.792op/s] or [+6.024%; +6.646%]

scenario:Benchmarks.Trace.SerilogBenchmark.EnrichedLog net472

  • 🟥 execution_time [+299.267ms; +301.579ms] or [+149.157%; +150.310%]

scenario:Benchmarks.Trace.SerilogBenchmark.EnrichedLog net6.0

  • 🟥 execution_time [+300.994ms; +302.961ms] or [+151.145%; +152.133%]

scenario:Benchmarks.Trace.SerilogBenchmark.EnrichedLog netcoreapp3.1

  • 🟥 execution_time [+302.867ms; +305.305ms] or [+153.595%; +154.831%]

scenario:Benchmarks.Trace.SingleSpanAspNetCoreBenchmark.SingleSpanAspNetCore net472

  • 🟥 execution_time [+299.930ms; +300.921ms] or [+149.607%; +150.101%]
  • 🟩 throughput [+65833489.674op/s; +66240826.176op/s] or [+47.944%; +48.241%]

scenario:Benchmarks.Trace.SingleSpanAspNetCoreBenchmark.SingleSpanAspNetCore net6.0

  • 🟥 execution_time [+415.195ms; +420.746ms] or [+516.368%; +523.272%]

scenario:Benchmarks.Trace.SingleSpanAspNetCoreBenchmark.SingleSpanAspNetCore netcoreapp3.1

  • 🟥 execution_time [+299.871ms; +301.097ms] or [+149.569%; +150.180%]
  • 🟩 throughput [+17889687.535op/s; +18886654.470op/s] or [+7.924%; +8.366%]

scenario:Benchmarks.Trace.SpanBenchmark.StartFinishScope net6.0

  • 🟩 throughput [+106826.385op/s; +117200.739op/s] or [+9.974%; +10.943%]

scenario:Benchmarks.Trace.SpanBenchmark.StartFinishScope netcoreapp3.1

  • 🟩 throughput [+47858.812op/s; +67370.425op/s] or [+5.540%; +7.798%]

scenario:Benchmarks.Trace.SpanBenchmark.StartFinishSpan net6.0

  • 🟩 throughput [+96384.650op/s; +125583.900op/s] or [+7.460%; +9.720%]

scenario:Benchmarks.Trace.SpanBenchmark.StartFinishSpan netcoreapp3.1

  • 🟩 throughput [+81722.585op/s; +89255.792op/s] or [+8.116%; +8.865%]

scenario:Benchmarks.Trace.SpanBenchmark.StartFinishTwoScopes net6.0

  • 🟩 throughput [+56443.876op/s; +61715.432op/s] or [+10.249%; +11.206%]

scenario:Benchmarks.Trace.SpanBenchmark.StartFinishTwoScopes netcoreapp3.1

  • 🟩 throughput [+24096.455op/s; +34616.463op/s] or [+5.394%; +7.748%]

scenario:Benchmarks.Trace.TraceAnnotationsBenchmark.RunOnMethodBegin net6.0

  • 🟩 throughput [+77267.893op/s; +97143.906op/s] or [+8.633%; +10.853%]

Known flaky benchmarks without significant changes:

  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan netcoreapp3.1
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_AddEvent_Sampled net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_AddEvent_Sampled net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_AddEvent_Sampled netcoreapp3.1
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_GetContext_Sampled net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_GetContext_Sampled net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_GetContext_Sampled netcoreapp3.1
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_SetAttributes_Sampled net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_SetAttributes_Sampled net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_SetAttributes_Sampled netcoreapp3.1
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_SetStatus_Sampled net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_SetStatus_Sampled net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_SetStatus_Sampled netcoreapp3.1
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_UpdateName_Sampled net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_UpdateName_Sampled net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.ActivityBenchmark.StartSpan_UpdateName_Sampled netcoreapp3.1
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan netcoreapp3.1
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_AddEvent_Sampled net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_AddEvent_Sampled net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_AddEvent_Sampled netcoreapp3.1
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_GetContext_Sampled net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_GetContext_Sampled net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_GetContext_Sampled netcoreapp3.1
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_RecordException_Sampled net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_RecordException_Sampled net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_RecordException_Sampled netcoreapp3.1
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_SetAttributes_Sampled net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_SetAttributes_Sampled net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_SetAttributes_Sampled netcoreapp3.1
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_SetStatus_Sampled net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_SetStatus_Sampled net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_SetStatus_Sampled netcoreapp3.1
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_UpdateName_Sampled net472
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_UpdateName_Sampled net6.0
  • scenario:Benchmarks.OpenTelemetry.InstrumentedApi.Trace.TelemetrySpanBenchmark.StartSpan_UpdateName_Sampled netcoreapp3.1
  • scenario:Benchmarks.Trace.ActivityBenchmark.StartStopWithChild net6.0
  • scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorMoreComplexBody net472
  • scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorSimpleBody net472
  • scenario:Benchmarks.Trace.Asm.AppSecWafBenchmark.RunWafRealisticBenchmark net472
  • scenario:Benchmarks.Trace.Asm.AppSecWafBenchmark.RunWafRealisticBenchmark net6.0
  • scenario:Benchmarks.Trace.Asm.AppSecWafBenchmark.RunWafRealisticBenchmark netcoreapp3.1
  • scenario:Benchmarks.Trace.Asm.AppSecWafBenchmark.RunWafRealisticBenchmarkWithAttack net472
  • scenario:Benchmarks.Trace.Asm.AppSecWafBenchmark.RunWafRealisticBenchmarkWithAttack netcoreapp3.1
  • scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSlice net6.0
  • scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSlice netcoreapp3.1
  • scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSliceWithPool net472
  • scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSliceWithPool net6.0
  • scenario:Benchmarks.Trace.CharSliceBenchmark.OriginalCharSlice net472
  • scenario:Benchmarks.Trace.CharSliceBenchmark.OriginalCharSlice net6.0
  • scenario:Benchmarks.Trace.CharSliceBenchmark.OriginalCharSlice netcoreapp3.1
  • scenario:Benchmarks.Trace.ILoggerBenchmark.EnrichedLog net472
  • scenario:Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatBenchmark net472
  • scenario:Benchmarks.Trace.RedisBenchmark.SendReceive net472
  • scenario:Benchmarks.Trace.RedisBenchmark.SendReceive netcoreapp3.1
  • scenario:Benchmarks.Trace.SpanBenchmark.StartFinishScope net472
  • scenario:Benchmarks.Trace.SpanBenchmark.StartFinishSpan net472
  • scenario:Benchmarks.Trace.SpanBenchmark.StartFinishTwoScopes net472
  • scenario:Benchmarks.Trace.TraceAnnotationsBenchmark.RunOnMethodBegin net472
  • scenario:Benchmarks.Trace.TraceAnnotationsBenchmark.RunOnMethodBegin netcoreapp3.1

@dd-trace-dotnet-ci-bot

dd-trace-dotnet-ci-bot Bot commented Jun 2, 2026

Copy link
Copy Markdown

Execution-Time Benchmarks Report ⏱️

Execution-time results for samples comparing This PR (8733) and master.

✅ No regressions detected - check the details below

Full Metrics Comparison

FakeDbCommand

Metric Master (Mean ± 95% CI) Current (Mean ± 95% CI) Change Status
.NET Framework 4.8 - Baseline
duration72.80 ± (72.88 - 73.21) ms73.65 ± (73.58 - 74.02) ms+1.2%✅⬆️
.NET Framework 4.8 - Bailout
duration78.73 ± (78.60 - 79.06) ms79.07 ± (78.88 - 79.25) ms+0.4%✅⬆️
.NET Framework 4.8 - CallTarget+Inlining+NGEN
duration1089.67 ± (1090.31 - 1096.10) ms1097.33 ± (1096.04 - 1103.49) ms+0.7%✅⬆️
.NET Core 3.1 - Baseline
process.internal_duration_ms22.67 ± (22.62 - 22.73) ms22.82 ± (22.76 - 22.88) ms+0.7%✅⬆️
process.time_to_main_ms84.55 ± (84.29 - 84.82) ms85.94 ± (85.67 - 86.21) ms+1.6%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed10.91 ± (10.90 - 10.91) MB10.92 ± (10.91 - 10.92) MB+0.1%✅⬆️
runtime.dotnet.threads.count12 ± (12 - 12)12 ± (12 - 12)+0.0%
.NET Core 3.1 - Bailout
process.internal_duration_ms22.69 ± (22.65 - 22.74) ms22.41 ± (22.37 - 22.45) ms-1.3%
process.time_to_main_ms86.52 ± (86.28 - 86.75) ms85.36 ± (85.14 - 85.58) ms-1.3%
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed10.94 ± (10.94 - 10.95) MB10.96 ± (10.96 - 10.96) MB+0.1%✅⬆️
runtime.dotnet.threads.count13 ± (13 - 13)13 ± (13 - 13)+0.0%
.NET Core 3.1 - CallTarget+Inlining+NGEN
process.internal_duration_ms212.35 ± (211.47 - 213.24) ms214.89 ± (214.00 - 215.78) ms+1.2%✅⬆️
process.time_to_main_ms540.48 ± (539.22 - 541.73) ms540.21 ± (538.95 - 541.46) ms-0.1%
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed48.40 ± (48.36 - 48.44) MB48.41 ± (48.38 - 48.44) MB+0.0%✅⬆️
runtime.dotnet.threads.count28 ± (28 - 28)28 ± (28 - 28)-0.3%
.NET 6 - Baseline
process.internal_duration_ms21.68 ± (21.63 - 21.72) ms21.34 ± (21.30 - 21.39) ms-1.5%
process.time_to_main_ms74.69 ± (74.49 - 74.89) ms73.20 ± (72.99 - 73.41) ms-2.0%
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed10.61 ± (10.61 - 10.61) MB10.63 ± (10.63 - 10.63) MB+0.2%✅⬆️
runtime.dotnet.threads.count10 ± (10 - 10)10 ± (10 - 10)+0.0%
.NET 6 - Bailout
process.internal_duration_ms21.42 ± (21.37 - 21.47) ms21.58 ± (21.53 - 21.63) ms+0.7%✅⬆️
process.time_to_main_ms74.93 ± (74.73 - 75.13) ms75.92 ± (75.70 - 76.14) ms+1.3%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed10.73 ± (10.73 - 10.73) MB10.75 ± (10.74 - 10.75) MB+0.2%✅⬆️
runtime.dotnet.threads.count11 ± (11 - 11)11 ± (11 - 11)+0.0%
.NET 6 - CallTarget+Inlining+NGEN
process.internal_duration_ms372.85 ± (370.68 - 375.02) ms371.06 ± (368.93 - 373.19) ms-0.5%
process.time_to_main_ms546.05 ± (544.88 - 547.22) ms547.21 ± (546.01 - 548.41) ms+0.2%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed49.89 ± (49.87 - 49.91) MB49.81 ± (49.79 - 49.84) MB-0.2%
runtime.dotnet.threads.count28 ± (28 - 28)28 ± (28 - 28)-0.1%
.NET 8 - Baseline
process.internal_duration_ms19.45 ± (19.42 - 19.48) ms19.37 ± (19.34 - 19.40) ms-0.4%
process.time_to_main_ms72.16 ± (72.01 - 72.32) ms71.63 ± (71.47 - 71.79) ms-0.7%
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed7.67 ± (7.66 - 7.68) MB7.70 ± (7.69 - 7.71) MB+0.4%✅⬆️
runtime.dotnet.threads.count10 ± (10 - 10)10 ± (10 - 10)+0.0%
.NET 8 - Bailout
process.internal_duration_ms19.62 ± (19.57 - 19.66) ms19.44 ± (19.40 - 19.47) ms-0.9%
process.time_to_main_ms75.15 ± (74.94 - 75.36) ms72.84 ± (72.69 - 72.99) ms-3.1%
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed7.71 ± (7.71 - 7.72) MB7.73 ± (7.72 - 7.74) MB+0.2%✅⬆️
runtime.dotnet.threads.count11 ± (11 - 11)11 ± (11 - 11)+0.0%
.NET 8 - CallTarget+Inlining+NGEN
process.internal_duration_ms294.61 ± (292.26 - 296.96) ms296.55 ± (294.28 - 298.83) ms+0.7%✅⬆️
process.time_to_main_ms495.06 ± (494.12 - 496.01) ms496.51 ± (495.57 - 497.45) ms+0.3%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed36.87 ± (36.84 - 36.91) MB36.96 ± (36.92 - 36.99) MB+0.2%✅⬆️
runtime.dotnet.threads.count27 ± (27 - 27)27 ± (27 - 27)+0.0%

HttpMessageHandler

Metric Master (Mean ± 95% CI) Current (Mean ± 95% CI) Change Status
.NET Framework 4.8 - Baseline
duration199.04 ± (198.95 - 199.92) ms200.63 ± (200.14 - 201.09) ms+0.8%✅⬆️
.NET Framework 4.8 - Bailout
duration203.44 ± (203.31 - 204.25) ms204.30 ± (203.95 - 204.86) ms+0.4%✅⬆️
.NET Framework 4.8 - CallTarget+Inlining+NGEN
duration1189.58 ± (1189.07 - 1194.93) ms1198.83 ± (1197.57 - 1203.19) ms+0.8%✅⬆️
.NET Core 3.1 - Baseline
process.internal_duration_ms191.35 ± (190.86 - 191.85) ms193.23 ± (192.72 - 193.75) ms+1.0%✅⬆️
process.time_to_main_ms82.74 ± (82.41 - 83.07) ms83.58 ± (83.28 - 83.87) ms+1.0%✅⬆️
runtime.dotnet.exceptions.count3 ± (3 - 3)3 ± (3 - 3)+0.0%
runtime.dotnet.mem.committed16.13 ± (16.10 - 16.16) MB16.10 ± (16.08 - 16.12) MB-0.2%
runtime.dotnet.threads.count20 ± (20 - 20)20 ± (19 - 20)-0.2%
.NET Core 3.1 - Bailout
process.internal_duration_ms193.66 ± (193.23 - 194.10) ms193.04 ± (192.61 - 193.47) ms-0.3%
process.time_to_main_ms85.28 ± (85.03 - 85.52) ms85.10 ± (84.81 - 85.39) ms-0.2%
runtime.dotnet.exceptions.count3 ± (3 - 3)3 ± (3 - 3)+0.0%
runtime.dotnet.mem.committed16.13 ± (16.10 - 16.16) MB16.15 ± (16.12 - 16.18) MB+0.1%✅⬆️
runtime.dotnet.threads.count21 ± (21 - 21)21 ± (20 - 21)-0.2%
.NET Core 3.1 - CallTarget+Inlining+NGEN
process.internal_duration_ms384.82 ± (383.48 - 386.16) ms387.47 ± (386.00 - 388.94) ms+0.7%✅⬆️
process.time_to_main_ms539.42 ± (538.01 - 540.84) ms540.64 ± (539.39 - 541.89) ms+0.2%✅⬆️
runtime.dotnet.exceptions.count3 ± (3 - 3)3 ± (3 - 3)+0.0%
runtime.dotnet.mem.committed57.33 ± (57.16 - 57.49) MB57.50 ± (57.30 - 57.69) MB+0.3%✅⬆️
runtime.dotnet.threads.count30 ± (30 - 30)30 ± (30 - 30)+0.3%✅⬆️
.NET 6 - Baseline
process.internal_duration_ms196.48 ± (195.97 - 196.98) ms199.29 ± (198.92 - 199.66) ms+1.4%✅⬆️
process.time_to_main_ms72.29 ± (71.99 - 72.60) ms73.46 ± (73.17 - 73.75) ms+1.6%✅⬆️
runtime.dotnet.exceptions.count4 ± (4 - 4)4 ± (4 - 4)+0.0%
runtime.dotnet.mem.committed16.37 ± (16.34 - 16.39) MB16.37 ± (16.35 - 16.40) MB+0.0%✅⬆️
runtime.dotnet.threads.count19 ± (19 - 19)19 ± (19 - 19)+1.0%✅⬆️
.NET 6 - Bailout
process.internal_duration_ms195.14 ± (194.66 - 195.62) ms197.54 ± (197.00 - 198.09) ms+1.2%✅⬆️
process.time_to_main_ms72.65 ± (72.45 - 72.85) ms73.77 ± (73.55 - 73.99) ms+1.5%✅⬆️
runtime.dotnet.exceptions.count4 ± (4 - 4)4 ± (4 - 4)+0.0%
runtime.dotnet.mem.committed16.46 ± (16.43 - 16.48) MB16.50 ± (16.47 - 16.52) MB+0.2%✅⬆️
runtime.dotnet.threads.count20 ± (20 - 20)20 ± (20 - 20)+0.1%✅⬆️
.NET 6 - CallTarget+Inlining+NGEN
process.internal_duration_ms585.92 ± (583.37 - 588.47) ms582.95 ± (580.51 - 585.40) ms-0.5%
process.time_to_main_ms542.62 ± (541.68 - 543.57) ms547.56 ± (546.51 - 548.61) ms+0.9%✅⬆️
runtime.dotnet.exceptions.count4 ± (4 - 4)4 ± (4 - 4)+0.0%
runtime.dotnet.mem.committed61.15 ± (61.06 - 61.24) MB61.13 ± (61.05 - 61.22) MB-0.0%
runtime.dotnet.threads.count31 ± (31 - 31)31 ± (31 - 31)-0.2%
.NET 8 - Baseline
process.internal_duration_ms194.67 ± (194.21 - 195.12) ms196.79 ± (196.33 - 197.25) ms+1.1%✅⬆️
process.time_to_main_ms71.75 ± (71.47 - 72.03) ms72.71 ± (72.43 - 72.99) ms+1.3%✅⬆️
runtime.dotnet.exceptions.count4 ± (4 - 4)4 ± (4 - 4)+0.0%
runtime.dotnet.mem.committed11.70 ± (11.68 - 11.72) MB11.74 ± (11.73 - 11.76) MB+0.3%✅⬆️
runtime.dotnet.threads.count18 ± (18 - 18)18 ± (18 - 18)-0.2%
.NET 8 - Bailout
process.internal_duration_ms194.53 ± (194.20 - 194.86) ms195.28 ± (194.89 - 195.67) ms+0.4%✅⬆️
process.time_to_main_ms72.52 ± (72.29 - 72.75) ms73.10 ± (72.90 - 73.29) ms+0.8%✅⬆️
runtime.dotnet.exceptions.count4 ± (4 - 4)4 ± (4 - 4)+0.0%
runtime.dotnet.mem.committed11.79 ± (11.77 - 11.82) MB11.81 ± (11.79 - 11.83) MB+0.2%✅⬆️
runtime.dotnet.threads.count19 ± (19 - 19)19 ± (19 - 19)+0.0%✅⬆️
.NET 8 - CallTarget+Inlining+NGEN
process.internal_duration_ms510.99 ± (508.42 - 513.56) ms510.25 ± (507.65 - 512.85) ms-0.1%
process.time_to_main_ms492.11 ± (491.24 - 492.98) ms496.89 ± (496.09 - 497.68) ms+1.0%✅⬆️
runtime.dotnet.exceptions.count4 ± (4 - 4)4 ± (4 - 4)+0.0%
runtime.dotnet.mem.committed50.65 ± (50.61 - 50.69) MB50.69 ± (50.65 - 50.72) MB+0.1%✅⬆️
runtime.dotnet.threads.count29 ± (29 - 29)29 ± (29 - 30)+0.5%✅⬆️
Comparison explanation

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 highlighted 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).

Duration charts
FakeDbCommand (.NET Framework 4.8)
gantt
    title Execution time (ms) FakeDbCommand (.NET Framework 4.8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8733) - mean (74ms)  : 70, 77
    master - mean (73ms)  : 71, 75

    section Bailout
    This PR (8733) - mean (79ms)  : 76, 82
    master - mean (79ms)  : 75, 82

    section CallTarget+Inlining+NGEN
    This PR (8733) - mean (1,100ms)  : 1046, 1153
    master - mean (1,093ms)  : 1051, 1135

Loading
FakeDbCommand (.NET Core 3.1)
gantt
    title Execution time (ms) FakeDbCommand (.NET Core 3.1)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8733) - mean (117ms)  : 112, 122
    master - mean (115ms)  : 109, 122

    section Bailout
    This PR (8733) - mean (115ms)  : 111, 120
    master - mean (117ms)  : 112, 122

    section CallTarget+Inlining+NGEN
    This PR (8733) - mean (792ms)  : 763, 821
    master - mean (788ms)  : 769, 808

Loading
FakeDbCommand (.NET 6)
gantt
    title Execution time (ms) FakeDbCommand (.NET 6)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8733) - mean (102ms)  : 98, 106
    master - mean (104ms)  : 99, 108

    section Bailout
    This PR (8733) - mean (105ms)  : 101, 109
    master - mean (103ms)  : 100, 107

    section CallTarget+Inlining+NGEN
    This PR (8733) - mean (951ms)  : 904, 999
    master - mean (953ms)  : 916, 990

Loading
FakeDbCommand (.NET 8)
gantt
    title Execution time (ms) FakeDbCommand (.NET 8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8733) - mean (99ms)  : 95, 102
    master - mean (99ms)  : 96, 103

    section Bailout
    This PR (8733) - mean (100ms)  : 98, 102
    master - mean (103ms)  : 99, 106

    section CallTarget+Inlining+NGEN
    This PR (8733) - mean (824ms)  : 791, 856
    master - mean (819ms)  : 778, 861

Loading
HttpMessageHandler (.NET Framework 4.8)
gantt
    title Execution time (ms) HttpMessageHandler (.NET Framework 4.8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8733) - mean (201ms)  : 195, 206
    master - mean (199ms)  : 193, 206

    section Bailout
    This PR (8733) - mean (204ms)  : 200, 209
    master - mean (204ms)  : 199, 208

    section CallTarget+Inlining+NGEN
    This PR (8733) - mean (1,200ms)  : 1165, 1236
    master - mean (1,192ms)  : 1156, 1228

Loading
HttpMessageHandler (.NET Core 3.1)
gantt
    title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8733) - mean (287ms)  : 280, 294
    master - mean (284ms)  : 277, 291

    section Bailout
    This PR (8733) - mean (287ms)  : 281, 293
    master - mean (289ms)  : 284, 294

    section CallTarget+Inlining+NGEN
    This PR (8733) - mean (966ms)  : 945, 987
    master - mean (966ms)  : 948, 985

Loading
HttpMessageHandler (.NET 6)
gantt
    title Execution time (ms) HttpMessageHandler (.NET 6)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8733) - mean (282ms)  : 276, 288
    master - mean (278ms)  : 272, 285

    section Bailout
    This PR (8733) - mean (280ms)  : 274, 286
    master - mean (277ms)  : 269, 285

    section CallTarget+Inlining+NGEN
    This PR (8733) - mean (1,163ms)  : 1121, 1205
    master - mean (1,157ms)  : 1119, 1196

Loading
HttpMessageHandler (.NET 8)
gantt
    title Execution time (ms) HttpMessageHandler (.NET 8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (8733) - mean (279ms)  : 271, 288
    master - mean (276ms)  : 268, 285

    section Bailout
    This PR (8733) - mean (278ms)  : 272, 285
    master - mean (277ms)  : 273, 281

    section CallTarget+Inlining+NGEN
    This PR (8733) - mean (1,039ms)  : 1003, 1075
    master - mean (1,035ms)  : 995, 1076

Loading

Comment thread tracer/test/Datadog.Trace.SourceGenerators.Tests/NativeEnvVarCoverageTests.cs Outdated
Comment thread tracer/test/Datadog.Trace.SourceGenerators.Tests/NativeEnvVarCoverageTests.cs Outdated
Comment thread tracer/test/Datadog.Trace.SourceGenerators.Tests/NativeEnvVarCoverageTests.cs Outdated
Comment thread tracer/test/Datadog.Trace.SourceGenerators.Tests/NativeEnvVarCoverageTests.cs Outdated
Comment thread tracer/test/Datadog.Trace.SourceGenerators.Tests/NativeEnvVarCoverageTests.cs Outdated
Comment thread tracer/test/Datadog.Trace.SourceGenerators.Tests/NativeEnvVarCoverageTests.cs Outdated
@bm1549
bm1549 force-pushed the brian.marks/native-config-scope-pr3 branch from 773fe74 to 961610d Compare June 4, 2026 17:34
@bm1549
bm1549 marked this pull request as ready for review June 5, 2026 16:10
@bm1549
bm1549 requested review from a team as code owners June 5, 2026 16:10

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 961610dc30

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread tracer/build/_build/NativeValidation/NativeConfigValidator.cs Outdated
Logger.Information("Native configuration validation passed: all {Count} native DD_* variables are registered with native scope", nativeVars.Count);
}

private static Dictionary<string, RegistryEntry> ParseRegistry(AbsolutePath supportedConfigurationsPath)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given this parsing should stay in sync with the source generator, should/could we just source link it in, to avoid the duplication. I feel like it could easily drift otherwise 🤔

Comment thread tracer/build/_build/NativeValidation/NativeConfigValidator.cs
Comment thread tracer/build/_build/NativeValidation/NativeConfigValidator.cs Outdated
Comment thread tracer/build/_build/NativeValidation/NativeConfigValidator.cs Outdated
Comment thread tracer/build/_build/NativeValidation/NativeConfigValidator.cs Outdated
Comment thread tracer/build/_build/NativeValidation/NativeConfigValidator.cs Outdated
Comment thread .github/workflows/verify_source_generated_changes_are_persisted.yml Outdated
Comment thread tracer/build/_build/NativeValidation/NativeConfigValidator.cs Outdated
bm1549 added a commit that referenced this pull request Jun 9, 2026
## Summary of changes

Adds `scope: managed` to every existing entry in
`supported-configurations.yaml`. Also adds `scope` to the YAML parser's
recognized property list so the field is accepted without throwing.

This is the first of three stacked PRs introducing scope tracking to the
configuration registry:
- **PR 1 (this)**: Add `scope: managed` to all existing entries — pure
data + one-line parser guard
- [**PR 2**](#8732): Full
scope infrastructure — parsing, generator enforcement, tests, docs
- [**PR 3**](#8733): All
native config variables — new `scope: native` entries + `scope: managed,
native` upgrades

## Reason for change

Prerequisite for scope-aware config registry. The parser must recognize
the field before the data lands; the generator infrastructure lands in
PR 2.

## Implementation details

- `YamlReader.cs`: one-line addition — `"scope"` added to the recognized
property list (prevents `InvalidOperationException` on unknown fields)
- `supported-configurations.yaml`: `scope: managed` inserted after every
`- implementation:` line across all 317 existing entries

No behavioral change — the generator does not yet read or act on the
scope field.

## Test coverage

Existing test suite passes unchanged. The generator ignores the scope
field at this point so no new tests are needed here.

## Other details

Part of a larger effort to register all native-consumed `DD_*` variables
in the config registry and enforce coverage via a CI test.

Co-authored-by: Claude Sonnet 4.6 <[email protected]>
@bm1549
bm1549 force-pushed the brian.marks/native-config-scope-pr2 branch from a5b94f6 to d823642 Compare June 9, 2026 22:47
@bm1549
bm1549 force-pushed the brian.marks/native-config-scope-pr3 branch from 360413f to bc96043 Compare June 9, 2026 22:51
Base automatically changed from brian.marks/native-config-scope-pr2 to master June 10, 2026 17:28
@bm1549
bm1549 force-pushed the brian.marks/native-config-scope-pr3 branch from bc96043 to 7103075 Compare June 10, 2026 17:39
@bm1549
bm1549 requested review from andrewlock and anna-git June 11, 2026 22:38
Comment thread tracer/src/Datadog.Trace.Tools.NativeConfigValidator/NativeConfigValidator.cs Outdated

@anna-git anna-git left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just left a last comment on comparisons
Also there's 2 vars showing up on CI with the wrong versions

@bm1549
bm1549 enabled auto-merge (squash) June 12, 2026 12:57

@andrewlock andrewlock left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM in general, but can we not use a dedicated project for this one validation, and instead make it a nuke target like other validation workflows?

Comment on lines +34 to +35
- name: "Validate native configurations are registered"
run: dotnet run -c Release --project tracer/src/Datadog.Trace.Tools.NativeConfigValidator/Datadog.Trace.Tools.NativeConfigValidator.csproj -- "${{ github.workspace }}"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The standard way to do this is to use a Nuke target, like we do for other validation workflows - can we keep that approach for consistency?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call - done in 46689e3, workflow now runs ./tracer/build.sh ValidateNativeConfigurations.

One thing: the target wraps the standalone NativeConfigValidator tool instead of inlining like CreateMissingNullabilityFile, because source-linking YamlReader into _build breaks the build_* jobs with CS2001 (Docker only COPYs _build). wdyt, or did you want it inline?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should have a standalone NativeConfigValidator... you could fix the source linking issue by reversing the copy. i.e. move the file to nuke, and source link into the source generator instead of the other way around

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I get it now...

Updated in 7a4dce8 !

@bm1549
bm1549 requested a review from andrewlock June 16, 2026 17:49
zacharycmontoya pushed a commit that referenced this pull request Jun 16, 2026
## Summary of changes

Adds `scope: managed` to every existing entry in
`supported-configurations.yaml`. Also adds `scope` to the YAML parser's
recognized property list so the field is accepted without throwing.

This is the first of three stacked PRs introducing scope tracking to the
configuration registry:
- **PR 1 (this)**: Add `scope: managed` to all existing entries — pure
data + one-line parser guard
- [**PR 2**](#8732): Full
scope infrastructure — parsing, generator enforcement, tests, docs
- [**PR 3**](#8733): All
native config variables — new `scope: native` entries + `scope: managed,
native` upgrades

## Reason for change

Prerequisite for scope-aware config registry. The parser must recognize
the field before the data lands; the generator infrastructure lands in
PR 2.

## Implementation details

- `YamlReader.cs`: one-line addition — `"scope"` added to the recognized
property list (prevents `InvalidOperationException` on unknown fields)
- `supported-configurations.yaml`: `scope: managed` inserted after every
`- implementation:` line across all 317 existing entries

No behavioral change — the generator does not yet read or act on the
scope field.

## Test coverage

Existing test suite passes unchanged. The generator ignores the scope
field at this point so no new tests are needed here.

## Other details

Part of a larger effort to register all native-consumed `DD_*` variables
in the config registry and enforce coverage via a CI test.

Co-authored-by: Claude Sonnet 4.6 <[email protected]>
bm1549 and others added 19 commits June 17, 2026 09:41
Adds 86 native-only configuration variables to supported-configurations.yaml
with scope: native, covering the tracer, shared loader, profiler, and
DD_INTERNAL_* components. Upgrades 25 entries from scope: managed to
scope: managed, native where native code also reads the variable.

Adds NativeEnvVarCoverageTests.cs, which verifies that every DD_*
variable read by WStr("DD_...") or L"DD_..." in native C++ source
(tracer/src, shared/src, profiler/src) has a corresponding YAML entry
with native in its scope.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
DD_IAST_SECURITY_CONTROLS_CONFIGURATION, DD_PROFILING_EXCEPTION_ENABLED,
DD_PROFILING_WALLTIME_ENABLED, and DD_TRACE_AZURE_FUNCTIONS_ENABLED all
exist in the Feature Parity Dashboard under implementation B, not A.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
…ENABLED

Both default to true in the profiler source (confirmed in Configuration.cpp).

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
…ries

Verified all 86 new native-only entries against the C++ source files.
Corrections applied:

Defaults (26 entries): various profiler tuning thresholds had null where
the C++ source has explicit fallback values; several booleans had false
where the source defaults to true (ETW enabled, timestamps as label, GC
threads CPU time, thread lifetime, lock contention, exception profiling,
etc.)

Types (1 entry): DD_INTERNAL_CIVISIBILITY_SPANID is an integer (uint64),
not string.

Products (3 entries): DD_PROFILER_PROCESSES and DD_PROFILER_EXCLUDE_PROCESSES
are read by the CLR auto-instrumentation profiler, not the Continuous
Profiler — product changed to Tracer. DD_HOSTNAME is read exclusively by
the profiler engine — product changed to Profiler.

Documentation (12 entries): corrected units (milliseconds vs minutes),
clarified that DD_INTERNAL_CUSTOM_CLR_PROFILER_PATH and
DD_INTERNAL_NATIVE_LOADER_PATH are output variables set by the loader (not
user overrides), fixed DD_DUMP_ILREWRITE_ENABLED to say "log" not "disk",
fixed DD_INTERNAL_WORKAROUND_77973_ENABLED to describe tiered compilation
(not IL verification), and several others.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Dictionary.TryAdd is not available on .NET Framework 4.8 / netstandard2.0,
which the SourceGenerators.Tests project targets. The local build on macOS
skips net48 so this only surfaced on the Windows CI runner.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Per review feedback: validating the native config registry from a managed
source-generator unit test was the wrong altitude — source-generator tests
should test generator behavior, and developers working only in the native
solutions would never run it locally.

- Adds NativeConfigValidator (tracer/build/_build/NativeValidation) and a
  ValidateNativeConfigurations Nuke target. It scans tracer/src/Datadog.Tracer.Native,
  shared/src, and profiler/src for DD_*/_DD_* env var literals and validates each is
  registered with native scope.
- Uses a plain string-literal regex (catches reads the previous WStr/L"..." patterns
  missed, e.g. MetadataProvider.cpp), includes the _DD_ prefix, excludes crashhandler.cpp
  (captures all DD vars at crash time), and allowlists two non-config literals
  (DD_ETW_DISPATCHER named pipe, DD_ETW_IPC_V1 magic version).
- Shares YamlReader.cs with the source generator via a csproj <Compile Include> link.
- Wires the target into the verify_source_generators GitHub workflow.
- Removes NativeEnvVarCoverageTests.cs from the managed test project.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
The native config scanner excluded .c sources, so the Linux ApiWrapper
(functions_to_wrap.c) was skipped - it reads DD_INTERNAL_CRASHTRACKING_PASSTHROUGH
and DD_INTERNAL_CRASHTRACKING_MINIDUMPNAME, neither of which was registered.
Adds .c (and .cxx) to the scanned extensions and registers both vars with
scope: native.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Every other DD_TELEMETRY_* entry uses product: Telemetry; this was the lone
Tracer outlier. No functional effect (native-only entries generate no
constant), but keeps the product grouping consistent with the prefix.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
…ss projects

The csproj <Compile Include> linked YamlReader.cs from the source generators
project via a ..\..\src path. That broke the build CI Docker images, whose
Dockerfiles COPY only the _build directory in isolation and pre-build it -
the cross-directory source file isn't in that context, so dotnet build failed
with CS2001 (and took down every build_* job).

NativeConfigValidator now parses supported-configurations.yaml with YamlDotNet,
which the build project already references. No cross-project file link, no
CS8632 suppression, and the validator no longer depends on the managed source
generators. Verified by compiling the _build project in an isolated copy
(mirroring the Docker COPY context).

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
…own action

Address andrewlock review feedback on the native-config validator:
- Relocate the validator out of the Nuke _build project into a standalone
  Datadog.Trace.Tools.NativeConfigValidator tool, run by a dedicated GitHub
  Action. A failure there means "update the registry" — distinct from the
  source-generator verification job, so it gets its own workflow.
- Reuse the source generator's YamlReader (source-linked) instead of a
  duplicate YamlDotNet parser, so the validator and the ConfigurationKeys
  generator can never drift out of sync.
- Drop the restriction that native-only entries cannot declare a const_name
  (harmless, and leaves room to source-generate native constants later).
- Use default (ordinal) comparers and include the registry file path in the
  "missing variable" error.
- Exclude the tool from CompileManagedSrc; like Tools.Runner it is built and
  restored only by its own workflow, not the main managed build.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
The documentation prose contradicted the structured `default:` field (which
matches the native code default) for these native-only keys:
- DD_INTERNAL_FAULT_TOLERANT_INSTRUMENTATION_ENABLED (default is false)
- DD_INTERNAL_SKIP_METHOD_BODY_ENABLED (default is true)
- DD_INTERNAL_TRACE_VERSION_COMPATIBILITY (default is true)

Correct the prose to match the runtime default.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Per andrewlock review feedback (r3412835267): run the native-config
validation through a Nuke target like the other validation workflows,
instead of `dotnet run` directly.

- Re-add the ValidateNativeConfigurations Nuke target, as a thin wrapper
  that runs the standalone Datadog.Trace.Tools.NativeConfigValidator tool.
  The logic stays in the tool (not inline in _build) because source-linking
  the generator's YamlReader into _build hits CS2001 in the isolated Docker
  build context - the reason it was moved out in the first place.
- Point validate_native_configurations.yml at `./tracer/build.sh
  ValidateNativeConfigurations`, keeping its own dedicated workflow.
- Expand the workflow path filter to include tracer/build.sh and
  tracer/build/_build/** so changes to the target or build entrypoint also
  trigger the gate.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Shorten the ValidateNativeConfigurations target comment to ~3 lines (in line
with the build files' norm) and drop the redundant path-filter comment.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
…t during CI incident)

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Per andrewlock review feedback: remove the standalone
Datadog.Trace.Tools.NativeConfigValidator tool and run validation inline in
the Nuke build, fixing the CS2001 source-link issue by reversing the copy
direction.

- Move YamlReader.cs + EquatableArray.cs into tracer/build/_build/NativeValidation/
  (kept namespace Datadog.Trace.SourceGenerators.Helpers). _build has the
  restrictive Docker build context (COPYs only _build), so the shared parser
  must live there; the source generator builds from a full checkout and now
  source-links them *from* _build (the reverse direction is what failed CS2001).
- Add _build/NativeValidation/NativeConfigValidator.cs and run it inline from
  the ValidateNativeConfigurations Nuke target (throws on failure).
- Delete the standalone tool project and its CompileManagedSrc exclude; drop
  its now-dead path from the workflow filter.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Rebased onto master; the validator (running on the merge commit) flagged 3
DD_INTERNAL_PROFILING_HEAPSNAPSHOT_* / TEST_HEAPSNAPSHOT vars that landed on
master with the heap-snapshot feature but were never registered. Add them with
the metadata read from Configuration.cpp:
- ..._HEAPSNAPSHOT_REFERENCE_TREE_FORMAT: int, default 1 (binary bitfield)
- ..._HEAPSNAPSHOT_SKIP_TRAVERSAL: boolean, default false
- ..._TEST_HEAPSNAPSHOT_INTERVAL: int seconds, default 0 (test-only)

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
@bm1549
bm1549 force-pushed the brian.marks/native-config-scope-pr3 branch from 0e5436b to f7a56ec Compare June 17, 2026 13:46

@andrewlock andrewlock left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for the iteration on this!

@bm1549
bm1549 merged commit df17d38 into master Jun 18, 2026
141 checks passed
@bm1549
bm1549 deleted the brian.marks/native-config-scope-pr3 branch June 18, 2026 08:44
@github-actions github-actions Bot added this to the vNext-v3 milestone Jun 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI Generated Largely based on code generated by an AI or LLM. This label is the same across all dd-trace-* repos area:configuration

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants