You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Finishes work started in
open-telemetry#35048
That PR only partially introduced a less complex processor architecture
by only using it for Sums.
Back then I was not sure of the best way to do it for multiple
datatypes, as generics seemed to introduce a lot of complexity
regardless of usage.
I since then did of a lot of perf analysis and due to the way Go works
(see gcshapes), we do not really gain anything at runtime from using
generics, given method calls are still dynamic.
This implementation uses regular Go interfaces and a good old type
switch in the hot path (ConsumeMetrics), which lowers mental complexity
quite a lot imo.
The value of the new architecture is backed up by the following
benchmark:
```
goos: linux
goarch: arm64
pkg: github.com/open-telemetry/opentelemetry-collector-contrib/processor/deltatocumulativeprocessor
│ sums.nested │ sums.linear │
│ sec/op │ sec/op vs base │
Processor/sums-8 56.35µ ± 1% 39.99µ ± 1% -29.04% (p=0.000 n=10)
│ sums.nested │ sums.linear │
│ B/op │ B/op vs base │
Processor/sums-8 11.520Ki ± 0% 3.683Ki ± 0% -68.03% (p=0.000 n=10)
│ sums.nested │ sums.linear │
│ allocs/op │ allocs/op vs base │
Processor/sums-8 365.0 ± 0% 260.0 ± 0% -28.77% (p=0.000 n=10)
```
<!--Describe what testing was performed and which tests were added.-->
#### Testing
This is a refactor, existing tests pass unaltered.
<!--Describe the documentation added.-->
#### Documentation
not needed
<!--Please delete paragraphs that you did not use before submitting.-->
0 commit comments