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
While varargs are convenient they allocate. That isn't usually a big deal but in the case of disabled log messages you'd prefer not to incur that penalty. My proposal is to remove the varargs from all log method, or at least the ones less than warning, and replace them with explicit 1, 2, and 3 argument versions. Those won't allocate at all except for boxing. Then create a version of the log methods that takes an array rather than varargs so that you have to intentionally allocate the array.
This should reduce the need for if (logger.isDebugEnabled()) style checks while at the same time making it more clear when a log invocation allocates. It'll still be possible to hide allocations in log invocations, just a little bit harder.
The text was updated successfully, but these errors were encountered:
While varargs are convenient they allocate. That isn't usually a big deal but in the case of disabled log messages you'd prefer not to incur that penalty. My proposal is to remove the varargs from all log method, or at least the ones less than warning, and replace them with explicit 1, 2, and 3 argument versions. Those won't allocate at all except for boxing. Then create a version of the log methods that takes an array rather than varargs so that you have to intentionally allocate the array.
This should reduce the need for
if (logger.isDebugEnabled())
style checks while at the same time making it more clear when a log invocation allocates. It'll still be possible to hide allocations in log invocations, just a little bit harder.The text was updated successfully, but these errors were encountered: