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
When using LoggingEventBuilder to addArgument or addKeyValue the only parameter options are Object or Supplier. If I use any primitive type (boolean, char, byte, short, int, long, float, double) then the compiler autoboxes them, even when the specified log level is not enabled and the Nop builder then discards them. This can generate a lot of eden garbage. This is an issue for me as I am working on a high throughput, garbage free, app which deals primarily in primitive types.
Adding these variants as additional methods eg addKeyValue("Foo", 1.23d) etc would delay the auto boxing until when, and only when, the logging is going to output something.
Currently the only surefire way to avoid this is to wrap such logging within an is<Level>Enabled block.
The text was updated successfully, but these errors were encountered:
@Webbot99 Thank you for this report. SLF4J 2.1.0-alpha0 to be released within the next few days will add default arg(boolean), arg(byte), arg(short)... methods to the LoggingEventBuilder interface with NOP implementations in NOPLoggingEventBuilder.
See the changes to LoggingEventBuilder in commit 154b4e4 for details.
When using LoggingEventBuilder to
addArgument
oraddKeyValue
the only parameter options are Object or Supplier. If I use any primitive type (boolean, char, byte, short, int, long, float, double) then the compiler autoboxes them, even when the specified log level is not enabled and the Nop builder then discards them. This can generate a lot of eden garbage. This is an issue for me as I am working on a high throughput, garbage free, app which deals primarily in primitive types.Adding these variants as additional methods eg
addKeyValue("Foo", 1.23d)
etc would delay the auto boxing until when, and only when, the logging is going to output something.Currently the only surefire way to avoid this is to wrap such logging within an
is<Level>Enabled
block.The text was updated successfully, but these errors were encountered: