[PROF-10125] Track unscaled allocation counts in allocation profiler #3770
Conversation
**What does this PR do?** This PR extends the allocation profiler to also track the unscaled allocation counts. Specifically, like other profile types, the allocation profiler assigns a weight to every sample, making it "represent" all the objects that weren't sampled. **Motivation:** For debugging, in corner cases, it comes in handy to know exactly how many samples the profiler observed, and what was the impact of scaling. As part of preparing the allocation profiler feature for GA, I'm adding this feature so we can use it to confirm the exact sample counts whenever needed. Note also this is something we do for the cpu/wall-time profiler, where we track the `cpu_or_wall_samples` as an exact count of how many samples were taken (and again, without the weight -- which in the case of those profilers, represents time). **Additional Notes:** N/A **How to test the change?** This change includes test coverage.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3770 +/- ##
=======================================
Coverage 97.91% 97.91%
=======================================
Files 1243 1243
Lines 74763 74829 +66
Branches 3608 3610 +2
=======================================
+ Hits 73205 73270 +65
- Misses 1558 1559 +1 ☔ View full report in Codecov by Sentry. |
![datadog-datadog-prod-us1[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
| { | ||
| 'cpu-time' => 123, | ||
| 'cpu-samples' => 456, | ||
| 'wall-time' => 789, | ||
| 'alloc-samples' => 4242, | ||
| 'alloc-samples-unscaled' => 2222, | ||
| 'timeline' => 1111, | ||
| } |
There was a problem hiding this comment.
Static Analysis Violation (ruby-best-practices/symbols-as-keys)
⚪ Notice - Best Practices - Link to Results
Consider using symbols instead of string hash keys
More information
In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.
The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.
To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.
At the moment, we cannot generate an appropriate fix for this violation.
Leave feedback in #static-analysis
| @@ -526,7 +539,7 @@ | |||
| # We use the same metric_values in all sample calls in before. So we'd expect | |||
| # the summed values to match `@num_allocations * metric_values[profile-type]` | |||
| # for each profile-type there in. | |||
| expected_summed_values = { :'heap-live-samples' => 0, :'heap-live-size' => 0, } | |||
| expected_summed_values = { 'heap-live-samples': 0, 'heap-live-size': 0, 'alloc-samples-unscaled': 0 } | |||
There was a problem hiding this comment.
Static Analysis Violation (ruby-best-practices/symbols-as-keys)
⚪ Notice - Best Practices - Link to Results
Consider using symbols instead of string hash keys
More information
In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.
The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.
To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.
At the moment, we cannot generate an appropriate fix for this violation.
Leave feedback in #static-analysis
What does this PR do?
This PR extends the allocation profiler to also track the unscaled allocation counts.
Specifically, like other profile types, the allocation profiler assigns a weight to every sample, making it "represent" all the objects that weren't sampled.
Motivation:
For debugging, in corner cases, it comes in handy to know exactly how many samples the profiler observed, and what was the impact of scaling.
As part of preparing the allocation profiler feature for GA, I'm adding this feature so we can use it to confirm the exact sample counts whenever needed.
Note also this is something we do for the cpu/wall-time profiler, where we track the
cpu_or_wall_samplesas an exact count of how many samples were taken (and again, without the weight -- which in the case of those profilers, represents time).Additional Notes:
N/A
How to test the change?
This change includes test coverage.