Merged
Conversation
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (8107) and master. ✅ No regressions detected - check the details below Full Metrics ComparisonFakeDbCommand
HttpMessageHandler
Comparison explanationExecution-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:
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 chartsFakeDbCommand (.NET Framework 4.8)gantt
title Execution time (ms) FakeDbCommand (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8107) - mean (69ms) : 67, 71
master - mean (68ms) : 66, 70
section Bailout
This PR (8107) - mean (73ms) : 71, 74
master - mean (72ms) : 71, 73
section CallTarget+Inlining+NGEN
This PR (8107) - mean (1,043ms) : 959, 1127
master - mean (1,020ms) : 975, 1066
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 (8107) - mean (107ms) : 104, 110
master - mean (106ms) : 104, 108
section Bailout
This PR (8107) - mean (108ms) : 106, 109
master - mean (107ms) : 106, 108
section CallTarget+Inlining+NGEN
This PR (8107) - mean (743ms) : 692, 794
master - mean (741ms) : 684, 797
FakeDbCommand (.NET 6)gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8107) - mean (94ms) : 92, 96
master - mean (94ms) : 92, 96
section Bailout
This PR (8107) - mean (95ms) : 94, 96
master - mean (94ms) : 94, 95
section CallTarget+Inlining+NGEN
This PR (8107) - mean (728ms) : 695, 761
master - mean (728ms) : 700, 756
FakeDbCommand (.NET 8)gantt
title Execution time (ms) FakeDbCommand (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8107) - mean (93ms) : 91, 95
master - mean (92ms) : 90, 94
section Bailout
This PR (8107) - mean (94ms) : 92, 96
master - mean (93ms) : 92, 94
section CallTarget+Inlining+NGEN
This PR (8107) - mean (642ms) : 628, 656
master - mean (640ms) : 625, 655
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 (8107) - mean (196ms) : 191, 202
master - mean (196ms) : 189, 204
section Bailout
This PR (8107) - mean (200ms) : 195, 204
master - mean (203ms) : 193, 213
section CallTarget+Inlining+NGEN
This PR (8107) - mean (1,155ms) : 1089, 1221
master - mean (1,160ms) : 1086, 1234
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 (8107) - mean (280ms) : 275, 284
master - mean (279ms) : 273, 284
section Bailout
This PR (8107) - mean (281ms) : 274, 288
master - mean (279ms) : 275, 283
section CallTarget+Inlining+NGEN
This PR (8107) - mean (949ms) : 904, 994
master - mean (933ms) : 878, 989
HttpMessageHandler (.NET 6)gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8107) - mean (274ms) : 268, 280
master - mean (272ms) : 266, 279
section Bailout
This PR (8107) - mean (273ms) : 269, 277
master - mean (273ms) : 268, 279
section CallTarget+Inlining+NGEN
This PR (8107) - mean (934ms) : 877, 991
master - mean (936ms) : 888, 984
HttpMessageHandler (.NET 8)gantt
title Execution time (ms) HttpMessageHandler (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8107) - mean (272ms) : 267, 276
master - mean (273ms) : 264, 283
section Bailout
This PR (8107) - mean (272ms) : 268, 276
master - mean (275ms) : 260, 290
section CallTarget+Inlining+NGEN
This PR (8107) - mean (843ms) : 826, 861
master - mean (849ms) : 823, 874
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
bouwkast
reviewed
Jan 28, 2026
Collaborator
bouwkast
left a comment
There was a problem hiding this comment.
I think we should put this in it's own workflow with a [labeled] trigger. Thoughts?
But this would be very nice 👍
Comment on lines
+28
to
+29
|
|
||
| - name: "Validate PR has labels" |
Collaborator
There was a problem hiding this comment.
I think it may be better if this lives in its own workflow (that is required) with a trigger such as
on:
pull_request:
types: [labeled]
That way whenever someone changes a label it will run this automatically and then update.
Separate workflow would get us around having to run AssignLabelsToPullRequest which seems a bit heavy
And [labeled] from what I see here would correctly run the workflow when labels are added/removed
But this would be a great help when doing the release!
Collaborator
Author
There was a problem hiding this comment.
Initially, I set it in a separate workflow. The main problem is about racing conditions with auto_label_prs.yml. This one can automatically add some tags after we fail the validation. For instance, if this check runs before auto_label_prs.yml, it could fail even if later auto_label_prs.yml adds a label. If we make it secuential, we have no racing issues.
About using types: [labeled], the labeled trigger would only fire when a label is added to a PR, right? If we have no labels, would it run (and fail)?
Collaborator
There was a problem hiding this comment.
That makes sense for the race condition
So if we keep it in this workflow we could do something like
on:
pull_request:
types: [opened, synchronize, reopened, labeled]
Then we can filter like so
- name: "Add labels"
if: github.event.action != 'labeled'
And I think that this would get us there so that they work and don't have a race condition
Collaborator
Author
There was a problem hiding this comment.
Yes, that would make sense. Thanks!
BenchmarksBenchmark execution time: 2026-01-30 17:09:10 Comparing candidate commit e3e5be7 in PR branch Found 9 performance improvements and 4 performance regressions! Performance is the same for 165 metrics, 14 unstable metrics. scenario:Benchmarks.Trace.AgentWriterBenchmark.WriteAndFlushEnrichedTraces net6.0
scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.AllCycleMoreComplexBody net472
scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorMoreComplexBody net472
scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorSimpleBody net472
scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorSimpleBody net6.0
scenario:Benchmarks.Trace.AspNetCoreBenchmark.SendRequest net6.0
scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces netcoreapp3.1
scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSliceWithPool net6.0
scenario:Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatBenchmark net6.0
scenario:Benchmarks.Trace.SingleSpanAspNetCoreBenchmark.SingleSpanAspNetCore net6.0
scenario:Benchmarks.Trace.SpanBenchmark.StartFinishSpan netcoreapp3.1
scenario:Benchmarks.Trace.SpanBenchmark.StartFinishTwoScopes net6.0
|
Collaborator
Author
|
Thanks for the feedback! |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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
This PR adds automated validation to ensure all pull requests have at least one label before merging. This eliminates the manual step of checking for unlabeled PRs during the release process.
Reason for change
During releases, we currently need to manually:
This PR implements automated label validation that runs on every pull request:
Implementation details
Test coverage
Other details