Skip to content

[chore][processor/batchprocessor] Improve batch processor edge case performance#13272

Closed
asweet-confluent wants to merge 3 commits into
open-telemetry:mainfrom
asweet-confluent:improve-batch-processor-perf
Closed

[chore][processor/batchprocessor] Improve batch processor edge case performance#13272
asweet-confluent wants to merge 3 commits into
open-telemetry:mainfrom
asweet-confluent:improve-batch-processor-perf

Conversation

@asweet-confluent
Copy link
Copy Markdown

@asweet-confluent asweet-confluent commented Jun 26, 2025

Description

As the batch size approaches one, the time complexity of the batch processor approaches O(n^2). This is caused by repeatedly counting the number of data points in a message. This commit introduces a "short-circuit" behavior that allows the core loop to exit quickly when the desired number of data points has been found.

Testing

Performance

I added a new benchmark for splitMetrics that tests performance with various numbers of metrics and a batch size of one. This is the before and after comparison produced by benchstat:

goos: linux
goarch: amd64
pkg: go.opentelemetry.io/collector/processor/batchprocessor
cpu: 11th Gen Intel(R) Core(TM) i9-11950H @ 2.60GHz
                             │   old.txt    │               new.txt               │
                             │    sec/op    │   sec/op     vs base                │
TraceSizeSpanCount-16          3.326n ± 13%   3.181n ± 5%   -4.37% (p=0.011 n=20)
BatchMetricProcessor-16        366.9µ ±  8%   416.7µ ± 7%  +13.58% (p=0.003 n=20)
MultiBatchMetricProcessor-16   419.6µ ±  6%   404.8µ ± 3%   -3.54% (p=0.021 n=20)
SplitMetrics1k-16              4.063m ±  7%   1.264m ± 4%  -68.88% (p=0.000 n=20)
SplitMetrics16k-16             841.3m ±  3%   189.4m ± 2%  -77.48% (p=0.000 n=20)
SplitMetrics64k-16             17.599 ±  5%    3.203 ± 9%  -81.80% (p=0.000 n=20)
geomean                        1.771m         862.5µ       -51.29%

I am surprised to see BatchMetricProcessor-16 performance regress here - does anyone have an idea of why that might be? I'll dig into it a bit more as well.

Correctness

I'm relying on the existing test suite to catch issues here.

@asweet-confluent asweet-confluent requested a review from a team as a code owner June 26, 2025 04:09
@asweet-confluent asweet-confluent requested a review from jmacd June 26, 2025 04:09
@asweet-confluent asweet-confluent force-pushed the improve-batch-processor-perf branch from 8d11cbe to 051a987 Compare June 26, 2025 04:13
@codecov
Copy link
Copy Markdown

codecov Bot commented Jun 26, 2025

Codecov Report

❌ Patch coverage is 97.77778% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.96%. Comparing base (8b73477) to head (4173d05).
⚠️ Report is 146 commits behind head on main.

Files with missing lines Patch % Lines
processor/batchprocessor/splitmetrics.go 95.74% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main   #13272   +/-   ##
=======================================
  Coverage   91.95%   91.96%           
=======================================
  Files         529      529           
  Lines       31446    31513   +67     
=======================================
+ Hits        28917    28981   +64     
- Misses       1998     2000    +2     
- Partials      531      532    +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@github-actions
Copy link
Copy Markdown
Contributor

This PR was marked stale due to lack of activity. It will be closed in 14 days.

Comment thread processor/batchprocessor/splitlogs.go Outdated
Comment thread processor/batchprocessor/splitmetrics.go
As the batch size approaches one, the time complexity of the batch
processor approaches O(n^2). This is caused by repeatedly counting the
number of data points in a message. This commit introduces a
"short-circuit" behavior that allows the core loop to exit quickly when
the desired number of data points has been found.
@asweet-confluent asweet-confluent force-pushed the improve-batch-processor-perf branch from 051a987 to 5af55af Compare July 15, 2025 22:48
@asweet-confluent asweet-confluent changed the title [processor/batchprocessor] Improve batch processor edge case performance [chore][processor/batchprocessor] Improve batch processor edge case performance Jul 15, 2025
@github-actions github-actions Bot removed the Stale label Jul 16, 2025
@github-actions
Copy link
Copy Markdown
Contributor

This PR was marked stale due to lack of activity. It will be closed in 14 days.

@github-actions github-actions Bot added Stale and removed Stale labels Jul 30, 2025
@jmacd
Copy link
Copy Markdown
Contributor

jmacd commented Aug 4, 2025

There has been a long effort to replace this code with new code.
#13547
It may have the same defect, see #8122.

@jmacd
Copy link
Copy Markdown
Contributor

jmacd commented Aug 4, 2025

@github-actions
Copy link
Copy Markdown
Contributor

This PR was marked stale due to lack of activity. It will be closed in 14 days.

@github-actions github-actions Bot added the Stale label Aug 20, 2025
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Sep 5, 2025

Closed as inactive. Feel free to reopen if this PR is still being worked on.

@github-actions github-actions Bot closed this Sep 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants