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

profiler: wrap delta profiling in a type #1483

Merged
merged 4 commits into from
Sep 30, 2022
Merged

Conversation

nsrip-dd
Copy link
Contributor

Wrap up delta profiling in a type with a Delta method. This type holds
any information about the previous profile needed to compute the delta
with the newest profile. The profiler keeps an instance of type for each
profile type which supports delta profiling. This better encapsulates
the implementation details of delta profiling, and facilitates upcoming
implementation changes.

As part of this change, pull the logic for merging in "extra" profiles
out of the delta profiling code path. This logic was implemented for C
allocation profiling, and the extra data was passed through to delta
profiling mainly for efficiency. However, merging in extra data is
orthogonal to delta profiling and we can find other ways to make that
more efficient if we need to.

@nsrip-dd nsrip-dd requested a review from a team as a code owner September 27, 2022 16:30
@nsrip-dd nsrip-dd added this to the 1.43.0 milestone Sep 27, 2022
felixge
felixge previously approved these changes Sep 29, 2022
Copy link
Member

@felixge felixge left a comment

Choose a reason for hiding this comment

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

LGTM, but it'd be nice to address the nits if they make sense to you. If not we can discuss in our 1on1 in a bit.

profiler/profiler.go Outdated Show resolved Hide resolved
// profile after computing the delta profile.
func (p *profiler) deltaProfile(name string, delta *pprofutils.Delta, curData []byte, extra ...*pprofile.Profile) (*profile, error) {
type deltaProfiler struct {
delta *pprofutils.Delta
Copy link
Member

Choose a reason for hiding this comment

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

NIT: I think I'd prefer the delta config to be an argument to the deltaProfiler.Delta() function. Otherwise it's kind of odd to have two copies of the same *pprofutils.Delta with different pointer semantic in two different places (here and on the profile type struct). The pointer here is meaningless (could be removed), and the pointer on the profile type has an overloaded meaning to indicate that delta profiling is not being used.

Again, I think it would all be a bit clearer if there weren't two copies of this type with the same data.

It's still fine to have a type that abstract the state of the delta profiler rather than directly using *pprofile.Profile to prepare for the upcoming change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Per our discussion, I've done the following things:

  • Make the Delta field for profileType a slice of pprofutils.ValueTypes and rename it to DeltaValues.
  • Change pprofutils.Delta so that it only computes deltas for the values it was explicitly given. This way, a length 0 pprofutils.ValueType means "don't compute delta profiles" so we don't overload the meaning of the Delta field.
  • Make the delta field of deltaProfiler a value rather than a pointer.

Wrap up delta profiling in a type with a Delta method. This type holds
any information about the previous profile needed to compute the delta
with the newest profile. The profiler keeps an instance of type for each
profile type which supports delta profiling. This better encapsulates
the implementation details of delta profiling, and facilitates upcoming
implementation changes.

As part of this change, pull the logic for merging in "extra" profiles
out of the delta profiling code path. This logic was implemented for C
allocation profiling, and the extra data was passed through to delta
profiling mainly for efficiency. However, merging in extra data is
orthogonal to delta profiling and we can find other ways to make that
more efficient if we need to.
Push more of the implementation details into the deltaProfiler type
Change the Delta field of profileType to DeltaValue, a list of values
for which to compute deltas. A length-0 DeltaValue means that the
profile type doesn't support delta profiles. This gets rid of the
overloaded meaning of Delta == nil meaning "do nothing" and
len(Delta.SampleTypes) == 0 mean "do everything".
@nsrip-dd nsrip-dd force-pushed the nick.ripley/delta-profile-type branch from 79e10c9 to d796776 Compare September 30, 2022 13:38
Copy link
Member

@pmbauer pmbauer left a comment

Choose a reason for hiding this comment

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

approving as it's late in CET :)

@nsrip-dd nsrip-dd merged commit 77945bc into main Sep 30, 2022
@nsrip-dd nsrip-dd deleted the nick.ripley/delta-profile-type branch September 30, 2022 17:26
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.

None yet

3 participants