-
Notifications
You must be signed in to change notification settings - Fork 834
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
Use standard ArrayList size rather than max number of links for initial span links allocation #6252
Use standard ArrayList size rather than max number of links for initial span links allocation #6252
Conversation
…al links allocation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #6252 +/- ##
============================================
+ Coverage 90.86% 90.88% +0.02%
- Complexity 6030 6033 +3
============================================
Files 651 651
Lines 17728 17728
Branches 1777 1777
============================================
+ Hits 16108 16112 +4
+ Misses 1105 1103 -2
+ Partials 515 513 -2 ☔ View full report in Codecov by Sentry. |
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'm curious to see this benchmarked against an implementation that uses LinkedList
, especially in cases for:
- no links (min)
- 11 links
- 128 links (max)
For no links, this is faulted in, so any data structure's |
I'd like to see before/after benchmarks for a variety of cases before changing this. |
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 seems the right thing to do for me even without benchmarks
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 seems the right thing to do for me even without benchmarks
I agree
I see where @trask and @jack-berg are coming from, and I don't want my ask to be a blocker. This is still probably a net improvement. I'm just a little hung up on the idea that a certain use case (messaging?) could generate lots of spans with ~11 links, which then requires one allocation for the first link and then another for the grow at 10. 🤷🏻 |
Fair question. The maximal case I can think of is a lambda triggered by an sqs message, with xray links turned on, and somehow the http-level invocation also carries b3, jaeger, and opentracing headers configured to be attached as links, which doesn't get anywhere near 11 links. I grepped for |
I also think this is a reasonable change. As for using a linked list, here is what Josh Block has to say about it https://twitter.com/joshbloch/status/583813919019573248?lang=en |
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.
seems fine. a few bytes saved per span seems like an ok incremental improvement.
Most spans that have links don't grow to contain the maximum number of links [Citation needed]. So, when faulting in a
links
list to hold them, there's no need to assume we'll need memory to hold the maximum.