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

Optimize the addition of TraceSegmentRef #5925

Closed
1 task
starboyate opened this issue Nov 30, 2020 · 7 comments
Closed
1 task

Optimize the addition of TraceSegmentRef #5925

starboyate opened this issue Nov 30, 2020 · 7 comments
Labels
question End user question and discussion.
Milestone

Comments

@starboyate
Copy link

Please answer these questions before submitting your issue.

  • Why do you submit this issue?
  • Feature or performance improvement

Question

when the extract() and continued() methods of TraceContext are called, TraceSegmentRef is created in the outer layer and then ref() is called to bind. If the corresponding TraceSegmentRef already exists, then no operation is done in the ref() method, here Will cause useless TraceSegmentRef object creation


Requirement or improvement

I think some common fields of ContextCarrier and ContextSnapshot can be extracted and defined as the parent class, and then provide a method to create TraceSegmentRef based on the parent class. In the ref() method of TraceSegment, the parameter is defined as the parent class, and then the ref() method returns TraceSegmentRef for external use

@wu-sheng
Copy link
Member

What do you mean in the outer layer? Could you make yourself clear? Do you mean without active running context?

@wu-sheng wu-sheng added question End user question and discussion. TBD To be decided later, need more discussion or input. labels Nov 30, 2020
@starboyate
Copy link
Author

starboyate commented Nov 30, 2020

I mean that the corresponding TraceSegmentRef will be created in the extract() and continued() methods of TracingContext, and then bound through the ref() method. However, if the TraceSegmentRef exists, then it will create a useless TraceSegmentRef object?

@wu-sheng
Copy link
Member

What do you mean useless? Ref is designed to be created. I can't see your point.

@starboyate
Copy link
Author

Maybe there is something wrong with what I described. I mean useless. That is, if there is a corresponding TraceSegmentRef in the LinkedList, the newly created TraceSegmentRef will not be added. This will create an object in the heap, but it will not be used
image

@wu-sheng
Copy link
Member

I am still not following. This method belongs to TraceSegment, which is owned by TracingContext. What is the issue?

@starboyate
Copy link
Author

image
image
I just think it can save the extra creation of TraceSegmentRef object, because the created TraceSegmentRef object may already exist. If the corresponding TraceSegmentRef object already exists, there is no need to create it and then judge whether it exists, which will result in the creation of TraceSegmentRef It doesn't work because it already exists in the LinkedList

@wu-sheng
Copy link
Member

Could you share the real use case? If you want to change source codes in your private usage, it is open to you. Feel free to do anything you like. In the upstream, I can't see the issue now.

@wu-sheng wu-sheng removed the TBD To be decided later, need more discussion or input. label Nov 30, 2020
@wu-sheng wu-sheng added this to the 8.4.0 milestone Nov 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question End user question and discussion.
Projects
None yet
Development

No branches or pull requests

2 participants