@@ -119,6 +119,12 @@ The "Iterations" column derivation is explained in [Google Benchmark documentati
119119| Logging int+float using MessageBuffer, JSON/threads:6 | 2110 ns | 6827 ns | 104646 |
120120| Multiprocess logging int+float using MessageBuffer, pattern: \% d \% m\% n | 3253 ns | 3253 ns | 214839 |
121121
122+
123+ This data is shown in the graph below. The single-threaded tests are shown in blue,
124+ while the multithreaded tests are shown in orange.
125+
126+ ![ ] ( images/performance-all.png )
127+
122128-# The "Appending" benchmarks just format the message (using PatternLayout) then discard the result.
123129-# The "Async" benchmarks test [ AsyncAppender] (@ref log4cxx::AsyncAppender) throughput, with logging events discarded in the background thread.
124130-# The "Logging" benchmarks write to a file using buffered output. Overhead is 2-3 times more when not using buffered output.
@@ -153,4 +159,19 @@ When logging floating point values from a high priority thread,
153159and you cannot use a background thread to format and write the log data,
154160the LOG4CXX_ [ level] _ FMT series of macros impose the least overhead.
155161
162+ The graphs below show the detailed performance results. The first graph shows
163+ multithreaded performance. As shown previously, multithreaded performance
164+ is generally much lower than single threaded due to locking contention:
165+
166+ ![ ] ( images/performance-multithread.png )
167+
168+ Single thread performance is shown below:
169+
170+ ![ ] ( images/performance-singlethread.png )
171+
172+ Note that in both instances, the content of the log message has a significant
173+ impact on performance. All of the tests shown in these graphs assume that
174+ the message is actually being logged. If the logger is not enabled, no messages
175+ are logged and performance is much better.
176+
156177[ asynchronous output setting ] :configuration-files.html#asynch-output
0 commit comments