-
Notifications
You must be signed in to change notification settings - Fork 10
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
refactor(profiling): backup sample types/period #403
Conversation
12fae0b
to
2ae7586
Compare
09926b4
to
4ff260b
Compare
2ae7586
to
31e33c2
Compare
5a3f760
to
e212171
Compare
e5524f2
to
1196378
Compare
f74b130
to
e102e07
Compare
0f98317
to
622db33
Compare
6ae45a4
to
83b7fa1
Compare
622db33
to
b68fe99
Compare
e9e34af
to
a1f5a62
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #403 +/- ##
=======================================
Coverage ? 65.57%
=======================================
Files ? 187
Lines ? 22873
Branches ? 0
=======================================
Hits ? 15000
Misses ? 7873
Partials ? 0
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks quite reasonable! The only part I'm not very confident about is the magic around internal memory management in BackupSampleTypesAndPeriod
, I left a few questions there.
/// Despite our manual drop order, it is still recommended to order the | ||
/// fields in the order things should be dropped. | ||
storage: ManuallyDrop<Vec<(String, String)>>, | ||
period: Option<((String, String), i64)>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: Out of curiosity, it seems that often we either omit or pass in a dummy period. I wonder if we should just get rid of this parameter for libdatadog API users (and libdatadog would always just insert a default one).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think "period" really makes sense anyway, because we smush everything into a single profile. Only really makes sense for certain sample types, and only then it depends on the implementation.
I think we can file this under "out of scope" for this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeap, for sure, more of a passing observation.
3883f89
to
fa7a21f
Compare
This breaks a dependency on the string table implementation details to be able to reset a profile and preserve the sample types and period. It does cause more allocations, though. Adds api::ValueType::new and uses it instead of constructing it directly, because in most cases with `new` it becomes a single line instead of four.
fa7a21f
to
724f019
Compare
/// Despite our manual drop order, it is still recommended to order the | ||
/// fields in the order things should be dropped. | ||
storage: ManuallyDrop<Vec<(String, String)>>, | ||
period: Option<((String, String), i64)>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
What does this PR do?
This refactors the Profile to backup the sample types and period outside of the string table.
Adds
api::ValueType::new
, and uses that instead of direct instantiation. In most cases, this shortens from 4 lines to 1 (but not always).Simplifies some
vec![...]
usage to[...]
in tests, since the vector isn't needed at all.Motivation
Restoring the sample types and period was the only place that used
fn get_string(&self, id: StringId) -> &str
outside of tests. Requiring the data structure to map in both directions to provide this functionality makes it hard for innovation. The upcomingStringTable
PR will not provide theStringId
to&str
functionality.Additional Notes
This is stacked on top of another PR, and there will be another PR stacked on this. They should all be merged at roughly the same time.
How to test the change?
This should be an internal change only, so test as usual.