Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize Metric Processing for Single Collector with Delta Temporality #3236

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

lalitb
Copy link
Member

@lalitb lalitb commented Jan 9, 2025

This introduces a fast path for cases with a single collector/reader using delta temporality. It skips unnecessary intermediate processing and directly generates metrics for callback, reducing memory usage and CPU overhead. This change is supposed to improve performance for common single-collector scenarios while retaining existing functionality for other cases.

Changes

Please provide a brief description of the changes here.

For significant contributions please make sure you have completed the following items:

  • CHANGELOG.md updated for non-trivial changes
  • Unit tests have been added
  • Changes in public API reviewed

Copy link

netlify bot commented Jan 9, 2025

Deploy Preview for opentelemetry-cpp-api-docs canceled.

Name Link
🔨 Latest commit 24ab035
🔍 Latest deploy log https://app.netlify.com/sites/opentelemetry-cpp-api-docs/deploys/6790453736d07d0008720ebb

@lalitb lalitb changed the title delta temporality optimization in case single collector is configured Metric collection optimization for delta temporality when one collector is configured. Jan 9, 2025
@lalitb lalitb changed the title Metric collection optimization for delta temporality when one collector is configured. Optimization of metric collection for delta temporality with a single configured collector. Jan 9, 2025
Copy link

codecov bot commented Jan 9, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.80%. Comparing base (031307b) to head (24ab035).

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #3236      +/-   ##
==========================================
+ Coverage   87.78%   87.80%   +0.02%     
==========================================
  Files         198      198              
  Lines        6308     6324      +16     
==========================================
+ Hits         5537     5552      +15     
- Misses        771      772       +1     
Files with missing lines Coverage Δ
sdk/src/metrics/state/temporal_metric_storage.cc 97.37% <100.00%> (-0.96%) ⬇️

@lalitb lalitb changed the title Optimization of metric collection for delta temporality with a single configured collector. Optimization of metric collection for delta temporality with a single configured reader. Jan 9, 2025
@lalitb lalitb changed the title Optimization of metric collection for delta temporality with a single configured reader. Optimize Metric Processing for Single Collector with Delta Temporality Jan 9, 2025
@lalitb lalitb marked this pull request as ready for review January 9, 2025 16:56
@lalitb lalitb requested a review from a team as a code owner January 9, 2025 16:56
@lalitb lalitb requested a review from ThomsonTan January 9, 2025 16:56
Comment on lines 55 to 56
if (collectors.size() == 1 && collector->GetAggregationTemporality(
instrument_descriptor_.type_) == AggregationTemporality::kDelta)
Copy link
Member

Choose a reason for hiding this comment

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

Nit: use the aggregation_temporarily local variable, from the previous line, in the if test.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks done.

return true;
});

return callback(metric_data);
Copy link
Member

Choose a reason for hiding this comment

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

No idea if this can happen or not, does the code in the fast path needs to pay attention to previous metrics in unreported_metrics_ ?

If not, consider to add a comment to explain why, and/or an assert to make sure there are no unreported metrics.

Copy link
Member Author

Choose a reason for hiding this comment

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

The fast-path doesn't need to consider the unreported_metrics, I have added comments to make it clear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants