[
https://issues.apache.org/jira/browse/LOG4J2-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15209586#comment-15209586
]
David Chapel edited comment on LOG4J2-1326 at 3/24/16 2:09 AM:
---------------------------------------------------------------
The {{log(CharSequence)}} method is definitely required.
A primary motivator would be for clients not requiring the log4j parameter
formatting. All message formatting would be handled by the client, taking care
of any app level garbage/performance requirements before passing to log4j. I
would expect most low latency zero garbage applications are already making use
of memory reuse strategies, which would naturally be extended to logging.
I would recommend the overloaded methods, they are easy to add and avoid
casting and branching on the critical path.
For some clients, the {{CharSequence}} parameters may be useful to avoid the
overhead of creating Strings, but here the check for {{Object}} to
{{CharSequence}} may be acceptable given that message formatting is taking
place. I like the idea of separating formatting from the logging call, with a
deferred formatting API (possibly Lamda based) .
The unrolled varargs methods (slf4j style) method are useful, assuming method
explosion in the API would be acceptable. The {{LevelLogger}} approach
suggested in {{LOG4J2-1278}} seems like a good way to mitigate, but does
introduce dual logging API's.
was (Author: david chapel):
The {{log(CharSequence)}} is definitely required.
A primary motivator would be for clients not requiring the log4j parameter
formatting. All message formatting would be handled by the client, taking care
of any app level garbage/performance requirements before passing to log4j. I
would expect most low latency zero garbage applications are already making use
of memory reuse strategies, which would naturally be extended to logging.
I would recommend the overloaded methods, they are easy to add and avoid
casting and branching on the critical path.
For some clients, the {{CharSequence}} parameters may be useful to avoid the
overhead of creating Strings, but here the check for {{Object}} to
{{CharSequence}} may be acceptable given that message formatting is taking
place. I like the idea of separating formatting from the logging call, with a
deferred formatting API (possibly Lamda based) .
The unrolled varargs methods (slf4j style) method are useful, assuming method
explosion in the API would be acceptable. The {{LevelLogger}} approach
suggested in {{LOG4J2-1278}} seems like a good way to mitigate, but does
introduce dual logging API's.
> Provide support for CharSequence parameters for low and zero-GC applications
> ----------------------------------------------------------------------------
>
> Key: LOG4J2-1326
> URL: https://issues.apache.org/jira/browse/LOG4J2-1326
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
> Affects Versions: 2.5
> Reporter: Vlad Shurupov
> Labels: features, performance
>
> Currently, the preferred way of logging character sequences in log4j 2 is by
> passing in tokens of type {{java.lang.String}}. It would be very beneficial
> if the API could provide methods that take {{java.lang.CharSequence}} tokens.
> This would allow high performance zero or low-GC applications to re-use the
> existing mutable structures implementing {{java.lang.CharSequence}} for
> continuous logging without new objects being created.
> A high-performance implementation of the logger would be expected to copy out
> the contents of a single or multiple instances of {{java.lang.CharSequence}}
> so that they could be re-used in the subsequent logging call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
