Improve performance of expanding and collapsing spans #2722
Conversation
DamianMaslanka5
requested review from
joe-elliott
and removed request for
a team
Use Set and Map to make lookups faster. This changes makes collapsing and expanding spans with large (10k) amount of children 200-500ms faster. Signed-off-by: Damian Maslanka <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2722 +/- ##
=======================================
Coverage 96.78% 96.78%
=======================================
Files 256 256
Lines 7933 7934 +1
Branches 2042 1990 -52
=======================================
+ Hits 7678 7679 +1
- Misses 254 255 +1
+ Partials 1 0 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
DamianMaslanka5
force-pushed
the
faster-collapse-expand
branch
from
49dfc62 to
6a0df1f
Compare
| }); | ||
| } | ||
|
|
||
| const memoizedSpanByID = memoizeOne((spans: Span[]) => new Map(spans.map(x => [x.spanID, x]))); |
There was a problem hiding this comment.
I know, but I am not sure if there is a good place for this data.
Creating a Map or a Set should not have measurable impact on performance, because it is usually done once per trace.
Also, if any refactoring is needed, then it would probably be best to do this in another PR.
yurishkuro
added
the
changelog:bugfix-or-minor-feature
|
@DamianMaslanka5 how is this PR different from #1975? |
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
@yurishkuro, #1975 tries to optimize So #1975 will not improve performance issue described in #2179 |
|
Is that PR still needed then? In your experiments with large traces how much initial calculation takes? |
@yurishkuro, yes #1975 is still needed, without changes from #1975, |
2 participants
Which problem is this PR solving?
closes #2179
Description of the changes
Use Set and Map to make lookups faster.
This changes makes collapsing and expanding spans with large (10k) amount of children 200-500ms faster.
Before
After
How to test
go run cmd/tracegen/main.go -service abcd -traces 1 -spans 10000