Uh oh!
There was an error while loading. Please reload this page.
Enable diagnostics in release - #1263
Conversation
There was a problem hiding this comment.
What rationele did you apply for deciding when to "protect" logging with a corresponding IsEnabled(...) check?
I see you protecting (cheap) warning-level logging, but not verbose-level logging. While you could expect more people to have warning and error level logging enabled by default, but almost no one enables verbose logging unless you're troubleshooting an issue.
Can you perform (and commit) a (a simple connect) benchmark that shows the impact on performance with all tracing disabled (with any without this PR applied)?
I don't think we have benchmarks where we make use of our docker infrastructure.
Would be nice to have this. @WojciechNagorski, am I right?
That said, I'd love to get this PR in! Thanks!
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Rob-Hague
commented
Dec 10, 2023
If the message is a literal string, I did not guard it.
I don't think a benchmark would be suited for such an end-to-end networking scenario (too much noise). The module shows as ~1% of CPU of a basic connect->listdirectory->downloadfiles scenario at verbose level, and does not show in a memory trace. Where we could use the benchmarks project is to define a number of scenarios from which it is easy to generate profiles for identifying where we should place the focus on performance. I found a nice blog which could be used as a reference 😉 |
| // server | ||
| var closeWaitResult = _session.TryWait(_channelClosedWaitHandle, ConnectionInfo.ChannelCloseTimeout); | ||
| if (closeWaitResult != WaitResult.Success) | ||
| if (closeWaitResult != WaitResult.Success && Diagnostics.IsEnabled(TraceEventType.Warning)) |
There was a problem hiding this comment.
I don't get why we need the condition Diagnostics.IsEnabled(TraceEventType.Warning) outside the log method.
what if someone forgot to check it?
There was a problem hiding this comment.
We don't need it, it just prevents doing any extra work like allocating string instances unnecessarily in the case that the log level is not enabled. But TBH I don't think it would make a material impact either way.
Rob-Hague
commented
Nov 23, 2024
Superseded by #1509 |

This should make troubleshooting apps easier