carterkozak commented on pull request #544: URL: https://github.com/apache/logging-log4j2/pull/544#issuecomment-893569664
> My benchmarks were with a single thread only. In practice, is this code executed in multiple log4j2 threads? As usual, the answer is “it depends” :-) in the default configuration we log synchronously so that all formatting occurs on the application thread which calls into a logger, so contention is bounded by the total number of application threads which may interact with a logger. In most cases access to appender manager instances is guarded to prevent clobbering once the formatted buffer has been generated and must be written. However using asynchronous logging there’s generally one background thread responsible for executing layouts and writing log data to wherever it’s stored, in that case there shouldn’t be contention on the name abbreviator. > The abbreviated name could be stored in the logger itself (all abbreviated names by pattern, to be precise), however this would require substantial architectural changes. this would certainly be challenging given each logger would need to be aware of all the appenders and their layouts reachable in the configuration. With enough map lookups anything can become slow! Given how (relatively) fast abbreviation is, it’s very possible an attempted optimization would make real-world performance worse. Do you have profiling data that shows abbreviation as a contributor to overall application congestion? I would imagine there would be many other components more likely to be the limiting factor. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
