Move importance/verbosity check earlier in logging #5992
Assignees
Labels
needs-design
Requires discussion with the dev team before attempting a fix.
performance
size:3
triaged
Projects
Milestone
Comments
Forgind
added
performance
needs-triage
|
Team Triage: We should have some performance profiling on this to justify the amount of work that would need to happen to get this to work. |
benvillalobos
added
needs-design
|
@ladipro This might be related to your current log level propagation optimization. |
ladipro
changed the title
Closed
4 tasks
ladipro
moved this from In Progress
to In Review
in Perf sprint Apr 19th - May 2nd 2021
ladipro
added a commit
that referenced
this issue
Aug 5, 2021
Fixes #5992 ### Context Some tasks spend a lot of time producing detailed log messages that end up going nowhere when building on the command line with Normal or Minimum verbosity. The goal of this PR is to expose an API for tasks to call to answer the question _"Are log messages of a given importance going to be consumed by a logger or should I not bother doing the work to create the output and skip calling `LogMessage` altogether?"_ ### Changes Made Added a public method named `LogsMessagesOfImportance` on `TaskLoggingHelper` to answer the question above. This PR focuses on command line scenarios such as `dotnet build` but the logic could be easily used/extended to work with 3rd party loggers (in IDEs for example) if we introduce a mechanism by which loggers promise to ignore too verbose messages. The solution presented herein is a bolt-on, making minimum changes to the existing logging infra. Third party loggers are assumed to be potentially logging everything so if at least one such logger is registered, the optimization is disabled. The new method is used internally by `TaskLoggingHelper` and by the otherwise spammy RAR task. ### Testing Existing and new unit tests, manual verification on command line as well as in Visual Studio. Performance testing has shown ~18 ms improvement in RAR run-time alone when building a single project with `dotnet build`. ### Notes This PR also introduces a new class `EngineServices` to serve as a replacement for the `IBuildEngineN` interfaces.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, it seems the importance check waits until it reaches the BuildEngine. Might it make more sense to check that a lot earlier, say, in TaskLoggingHelper instead? It would be a little less centralized, and we'd have to expose it, but then we wouldn't have to create strings that we're never going to log, and we can perform some other little optimizations along the way if getting the information that we're not going to log would take a lot of time.
The text was updated successfully, but these errors were encountered: