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

Reduce allocations required to create a TransformNode #72375

Merged

Conversation

ToddGrun
Copy link
Contributor

@ToddGrun ToddGrun commented Mar 3, 2024

Instead of wrapping the user function and passing that into the TransformNode ctor, we instead give the option of passing in a flag to indicate whether the TransformNode should do the try/catch itself.

This looks to save about 0.5% in allocations in the RichCopyTest.CopyPlain speedometer via results here from this test insertion.

Instead of wrapping the user function and passing that into the TransformNode ctor, we instead give the option of passing in a flag to indicate whether the TransformNode should do the try/catch itself.

I believe this will save about 0.5% in allocations in the RichCopyTest.CopyPlain speedometer test and will do a test insertion to validate, keeping this as a draft PR until validated.
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Mar 3, 2024
@ToddGrun ToddGrun changed the title WIP: Reduce allocations required to create a TransformNode Reduce allocations required to create a TransformNode Mar 5, 2024
@ToddGrun ToddGrun marked this pull request as ready for review March 5, 2024 01:43
@ToddGrun ToddGrun requested a review from a team as a code owner March 5, 2024 01:43
@ToddGrun
Copy link
Contributor Author

ToddGrun commented Mar 5, 2024

@dotnet/roslyn-compiler -- ptal

@jaredpar
Copy link
Member

jaredpar commented Mar 5, 2024

@jjonescz, @chsienki PTAL

@ToddGrun
Copy link
Contributor Author

ToddGrun commented Mar 6, 2024

Any thoughts @chsienki ?

throw new UserFunctionException(e);
}
}
else
Copy link
Contributor

Choose a reason for hiding this comment

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

We could get rid of the if/else and edit the when on the catch so we don't catch if !_wrapUserFunc

I'd then renamed _wrapUserFunc to just CatchAnalyzerExceptions

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Went ahead and made the modification to the when clause.

I can be convinced otherwise, but I think I'd prefer to keep the current name (_wrapUserFunc) as the existing _func name doesn't convey a relationship to analyzers.

Copy link
Contributor

Choose a reason for hiding this comment

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

Generators are analyzers too, we sort of use the terms interchangeably inside the compiler, but I also don't have strong feelings on the naming.

@ToddGrun
Copy link
Contributor Author

ToddGrun commented Mar 6, 2024

/azp run

Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@ToddGrun ToddGrun merged commit d24b5bb into dotnet:main Mar 6, 2024
24 of 27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants