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

Trace thread local performance refactor #9620

Closed

Conversation

saintentropy
Copy link
Contributor

@saintentropy saintentropy commented Apr 3, 2019

Purpose

The purpose of this PR is move the backing implementation in TraceUtils from a thread data slot to a thread relative static field per Microsofts recommendations for performance.. This backing implementation is the data mechanism the VM utilizes to send information to and receive information from the zero-touch and NodeModel nodes invoked function contexts outside of the typical input parameters and return values. This PR does not relate to the other half of trace which is the serialization/deserialization of trace data to/from the .DYN file nor the data structure in the VM that keeps track of the current trace values per CallSite. This PR does not change the public API's in DynamoService for use of trace with a Node (ie GetTraceData and SetTraceData). It does however simplify the internal methods utilized within the VM to set, get, and clear trace.

Declarations

Check these if you believe they are true

  • The code base is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning, and are documented in the API Changes document.

Reviewers

(FILL ME IN) Reviewer 1 (If possible, assign the Reviewer for the PR)

(FILL ME IN, optional) Any additional notes to reviewers or testers.

FYIs

(FILL ME IN, Optional) Names of anyone else you wish to be notified of

@saintentropy saintentropy changed the title [WIP] Trace thread local performance refactor Trace thread local performance refactor Apr 4, 2019
{
var val = traceRet[TRACE_KEY];
newTraceData.Data = val;
Copy link
Contributor

Choose a reason for hiding this comment

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

So in the case of ret being null, it looks like earlier newTraceData.Data was also being set to null. Now that there's an else condition, is that no longer the case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looks like newTraceData.Data should always be null as you arrive here. Setting to null would be unnecessary.

@@ -1,98 +0,0 @@
using System;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should obsolete this class and not remove it yet just so we don't break the API for binary compatibility and make a note to remove this in 3.0.

@aparajit-pratap
Copy link
Contributor

Closing this in favor of #9665

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.

2 participants