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

pkg/query: Create flamegraph_arrow #3069

Merged
merged 28 commits into from
Jun 22, 2023
Merged

pkg/query: Create flamegraph_arrow #3069

merged 28 commits into from
Jun 22, 2023

Conversation

metalmatze
Copy link
Member

This creates a new flame graph representation. Instead of creating the flame graph with Go structs directly, we utilize Apache Arrow to create a record including the rows of each location.

The way the arrow schema looks can be viewed in pkg/query/flamegraph_arrow.go and pkg/query/flamegraph_arrow_test.go contains an example of what we currently have.

The API currently doesn't expose this type just yet. Only the enum type was added to proto to be able to call RenderReport with QueryRequest_REPORT_TYPE_FLAMEGRAPH_ARROW.

)

const (
flamegraphFieldMappingStart = "mapping_start"
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if we can make this code cleaner by having a map from field name to some struct that encapsulates the arrow type and holds a reference to the builder.

@metalmatze
Copy link
Member Author

Next week, I'll bring this PR into a mergeable state. So we can make progress on smaller follow-up PRs.

The follow ups on the Go side should be:

  1. Trimming
  2. pprof label support
  3. cleaning up (potentially making our record builder using generics)
  4. Exposing the new type from our API (this is more likely part of the UI changes)

@metalmatze
Copy link
Member Author

There's one more fix I need to do in upstream Arrow (due to which the CI is going to fail here)

Copy link
Member

@brancz brancz left a comment

Choose a reason for hiding this comment

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

Nice work! Happy to merge this and iterate!

int32 height = 3;

// trimmed is the amount of cumulative value trimmed from the flame graph.
int64 trimmed = 4;
Copy link
Member

Choose a reason for hiding this comment

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

do we strictly need this?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is mostly used for debugging, otherwise, we don't really need it.

@metalmatze
Copy link
Member Author

The new changes break the tests again. I'll fix those tomorrow.

metalmatze and others added 25 commits June 22, 2023 11:20
Additionally, we now update the root's row cumulative value and the end and correctly build the children lists.
…regating

This has huge performance improvements due to not allocating strings when converting the bytes to string.
…prof labels

This will allow users to specify if pprof labels should be ignored and aggregated away, or if the flame graph should consider their values and group by the once that are equal.
Also improve ergonomics by introducing isRoot, isLeaf and parent helper structs and funcs.
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