Hi,
I've encountered a memory allocation issue during logging. After some investigation I figured out that DebugLogger creates new strings instead of leveraging StringBuilder (see lines 59 and 63):
https://github.com/dotnet/runtime/blob/0923e83c58c9b4ea7fbf8b0998d5dfb5de6d2ae7/src/libraries/Microsoft.Extensions.Logging.Debug/src/DebugLogger.cs#L59-L66
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
Tagging subscribers to this area: @maryamariyan
See info in area-owners.md if you want to be subscribed.
This API is intended to be used when a debugger is attached and the logger is active. The method early-exits without allocation when the logger is not enabled.
Is avoiding allocations really critical in this scenario?
Agree with @grabyourpitchforks. Can you explain why you care about allocations when debugger is attached? Is it creating false positives or otherwise harming your ability to test/debug?
Agree with @GrabYourPitchforks that there is no issue when debugger is not attached
@ericstj, the only way this issue harms is by a highlight from memory allocation checker:

I've created the issue to escalate it to you guys so that you are aware of it and decide whether to fix it or leave it as is
Sure, and the report is definitely appreciated! But to be really actionable by us we'd need something more than that an automated tool said "there's an allocation here." There are allocations everywhere in .NET. And that's just fine - it's a rapid application development platform. It's not intended to be completely allocation-free save for some specially crafted routines which are commonly used in hyper-optimized application pipelines. If there's evidence that this is negatively impacting real-world apps, though, we'd definitely want to be made aware of it!
That makes sense, thanks for the feedback, @GrabYourPitchforks!