ghost
commented
1 year ago Tagging subscribers to this area: @dotnet/area-extensions-logging See info in area-owners.md if you want to be subscribed.
Issue Details
Looking at a size trace of an asp.net app using Npgsql and I'm seeing a few things around logging that add significant bloat. Our messages: https://github.com/npgsql/npgsql/blob/274a1d174b44640d727f57751921541f335d6ffb/src/Npgsql/LogMessages.cs#L20 We easily add 100+ kb for Npgsql because of: https://github.com/dotnet/runtime/issues/85116. Good to see it's being tracked for 9.0. Next I noticed some of our methods have method parameters but no corresponding structured message parameter. Regardless LoggerMessageGenerator generates a TState struct and adds generic code bloat. Continuing analysis of LoggerMessageGenerator codegen I noticed we have a ton of messages all logging the same parameters, today each gets their own struct and resulting generic code bloat throughout the logging stack. It would be useful if a Type to be used could be passed to the attribute allowing us to share definitions, or alternatively the generator might be able to do deduplication within an assembly automatically.
| Author: | NinoFloris |
|---|---|
| Assignees: | - |
| Labels: | `area-Extensions-Logging` |
| Milestone: | - |
Looking at a size trace of an asp.net app using Npgsql and I'm seeing a few things around logging that add significant bloat.
Our messages: https://github.com/npgsql/npgsql/blob/274a1d174b44640d727f57751921541f335d6ffb/src/Npgsql/LogMessages.cs#L20
We easily add 100+ kb for Npgsql because of: https://github.com/dotnet/runtime/issues/85116. Good to see it's being tracked for 9.0.
Next I noticed some of our methods have method parameters but no corresponding structured message parameter. Regardless LoggerMessageGenerator generates a TState struct and adds generic code bloat.
Continuing analysis of LoggerMessageGenerator codegen I noticed we have a ton of messages all logging the same parameters, today each gets their own struct and resulting generic code bloat throughout the logging stack. It would be useful if a Type to be used could be passed to the attribute allowing us to share definitions, or alternatively the generator might be able to do deduplication within an assembly automatically.