[pdata] Use pool-aware constructors in gRPC service handlers#14763
Conversation
a3b7ea5 to
4c4b669
Compare
|
/easycla |
4c4b669 to
6aef99c
Compare
|
This should have a changelog entry. |
Codecov Report❌ Patch coverage is
❌ Your patch status has failed because the patch coverage (75.00%) is below the target coverage (95.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #14763 +/- ##
==========================================
- Coverage 91.30% 90.35% -0.95%
==========================================
Files 699 700 +1
Lines 44940 53801 +8861
==========================================
+ Hits 41034 48614 +7580
- Misses 2761 4042 +1281
Partials 1145 1145 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
c6192c5 to
3145851
Compare
|
Please take another look |
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
3145851 to
c480870
Compare
|
I think this change still makes sense to merge |
dmathieu
left a comment
There was a problem hiding this comment.
Sorry for the staleness here. This definitely makes sense.
The gRPC service handlers for all four signal types allocate the
top-level ExportXxxServiceRequest with bare new(), bypassing the
sync.Pool when pdata.useProtoPooling is enabled. This means objects
returned to the pool via Delete are never retrieved, so the pool
accumulates unreused objects.
Replace new() with the pool-aware New*() constructors so the
top-level request struct participates in the pool lifecycle.
benchstat (20 runs, pdata.useProtoPooling=true, 10k logs/request):
│ old (new()) │ new (New*()) │
│ sec/op │ sec/op vs base │
GRPCLogsSequentialPooling-12 3.858m ± 2% 3.811m ± 1% ~ (p=0.165 n=20)
│ B/op │ B/op vs base │
GRPCLogsSequentialPooling-12 3.551Mi ± 2% 3.523Mi ± 1% ~ (p=0.445 n=20)
│ allocs/op │ allocs/op vs base│
GRPCLogsSequentialPooling-12 75.46k ± 0% 75.46k ± 0% ~ (p=0.867 n=20)
No measurable perf difference (1 alloc out of 75k), but this is a
correctness fix for the pool lifecycle.
Assisted-by: Claude Opus 4.6
c480870 to
0c24389
Compare
|
@dmathieu rebased against current |
a54d19e
|
Thank you for your contribution @kevinburkesegment! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey. |
Description
The gRPC service handlers for all four signal types allocate the top-level ExportXxxServiceRequest with bare new(), bypassing the sync.Pool when pdata.useProtoPooling is enabled. This means objects returned to the pool via Delete are never retrieved, so the pool accumulates unreused objects.
Replace new() with the pool-aware New*() constructors so the top-level request struct participates in the pool lifecycle.
benchstat (20 runs, pdata.useProtoPooling=true, 10k logs/request):
No measurable perf difference (1 alloc out of 75k), but this is a correctness fix for the pool lifecycle.
Assisted-by: Claude Opus 4.6
Link to tracking issue
Fixes #
Testing
Documentation