Skip to content

Conversation

@stephentoub
Copy link
Member

This started with my seeing ~45K of string-related allocations in a profile coming from GetCSharpString, even though most of the strings didn't require escaping; the first commit here addresses that. But then the second commit is me questioning why we even need to be doing any C#-related escaping as part of IL generation and reflection emit. Is there a good reason for it?

@stephentoub stephentoub added this to the 7.0.0 milestone May 1, 2022
@stephentoub stephentoub requested review from StephenMolloy and krwq May 1, 2022 00:45
@ghost ghost assigned stephentoub May 1, 2022
Copy link
Member

@danmoseley danmoseley left a comment

Choose a reason for hiding this comment

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

assuming there is indeed no need for the escaping, the change looks good.

@danmoseley
Copy link
Member

Presumably when the values are read, they're either unescaped or not. If the former, this breaks them, if the latter then the code is already broken and presumably missing tests?

…arpString

- If there's nothing to escape, we can just return the original string without creating a StringBuilder
- These strings are typically very short.  We can use ValueStringBuilder and stack space.
@stephentoub
Copy link
Member Author

I've removed the second commit; I still don't know why the C#-escaping is there, but we can bank the benefits of the first commit and discuss the need for the method at all separately.

@stephentoub stephentoub merged commit b9fdcc5 into dotnet:main May 3, 2022
@stephentoub stephentoub deleted the xmlcsharpstring branch May 3, 2022 14:25
@ghost ghost locked as resolved and limited conversation to collaborators Jun 2, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants