You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We easily add 100+ kb for Npgsql because of: #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.
The text was updated successfully, but these errors were encountered:
We easily add 100+ kb for Npgsql because of: #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.
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: #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.
The text was updated successfully, but these errors were encountered: