-
Notifications
You must be signed in to change notification settings - Fork 230
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: Improve flamegraph performance through dictionary unification #3651
Conversation
🤖 Meticulous spotted visual differences in 26 of 171 screens tested: view and approve differences detected. Last updated for commit b8255ee. This comment will update as new commits are pushed. |
b13fa21
to
64e9ecb
Compare
86dba7e
to
a307896
Compare
Previously we looked at each individual string to be inserted into the resulting flamegraph, which was very inefficient since strings occur many times over. That causes dictionary building to be inefficient, but also comparisons are done on strings rather than integers. Changing this to use dictionary unification and transposing yielded a very good performance improvement: ``` $ benchstat old.txt new.txt name old time/op new time/op delta ArrowFlamegraph-10 5.95ms ± 0% 3.38ms ± 0% -43.28% (p=0.008 n=5+5) ```
3100faf
to
092f970
Compare
The latest commit (removing maps from tracking labels) improves it by another 15%:
|
092f970
to
d38b713
Compare
pkg/query/flamegraph_arrow.go
Outdated
@@ -270,9 +281,106 @@ func generateFlamegraphArrowRecord(ctx context.Context, mem memory.Allocator, tr | |||
return record, fb.cumulative, fb.maxHeight + 1, 0, nil | |||
} | |||
|
|||
type transpositions struct { | |||
mappingIDIndicesData *array.Data |
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.
nit: I think it would be nicer to unify these *Data
and *Indices
fields into a struct to halve the number of fields here and e.g. Release
calls.
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.
as in encapsulate them in a struct, or how do you mean?
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.
Yes
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.
You even included the UI changes 🎉
pkg/query/flamegraph_arrow.go
Outdated
if r.Mapping.IsValid(locationRow) { | ||
fb.builderMappingStart.Append(r.MappingStart.Value(locationRow)) | ||
fb.builderMappingLimit.Append(r.MappingLimit.Value(locationRow)) | ||
fb.builderMappingOffset.Append(r.MappingOffset.Value(locationRow)) | ||
fb.builderMappingFileIndices.Append(t.mappingFileIndices.Value(r.MappingFile.GetValueIndex(locationRow))) | ||
fb.builderMappingBuildIDIndices.Append(t.mappingIDIndices.Value(r.MappingBuildID.GetValueIndex(locationRow))) |
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.
Oh, very nice!
@@ -26,16 +32,20 @@ export function nodeLabel( | |||
showBinaryName: boolean | |||
): string { | |||
const functionName: string | null = table.getChild(FIELD_FUNCTION_NAME)?.get(row); | |||
const labelsOnly: boolean | null = table.getChild(FIELD_LABELS_ONLY)?.get(row); | |||
const labels: string | null = table.getChild(FIELD_LABELS)?.get(row); | |||
console.log(labelsOnly, labels); |
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.
We probably want to remove this before merging.
return functionName; | ||
} | ||
|
||
if (level === 1 && labelsOnly !== null && labelsOnly && labels !== null && labels !== '') { |
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.
If we now have this labelsOnly
column to read from, we can probably remove passing the level
all the way down.
79365ec
to
27c19e1
Compare
bb10c79
to
b8255ee
Compare
Previously we looked at each individual string to be inserted into the resulting flamegraph, which was very inefficient since strings occur many times over. That causes dictionary building to be inefficient, but also comparisons are done on strings rather than integers.
Changing this to use dictionary unification and transposing yielded a very good performance improvement: