The performance metrics can be generated on anybody's system, as the code used to generate the performance results is checked in: https://github.com/apache/logging-log4cxx/blob/397c78245b7caf3e194b3fd3e052f91168d0a74d/src/test/cpp/benchmark/benchmark.cpp
The graphs are there to help interpret the data in the tables in a clearer fashion. The more interesting thing(to me at least) is the relative difference in how messages are logged. There's a decent difference in using libfmt vs. using the ostream<< operators, while multithreading understandably decimates the performance due to locking contention. It's more for informational purposes for anybody using log4cxx, to show what to look for if performance is critical. Disabling a logger results in a bar that is off the charts, so that's not included. -Robert Middleton On Tue, Nov 4, 2025 at 3:43 PM Volkan Yazıcı <[email protected]> wrote: > Hey Robert, > > I see that you're working on some performance graphs for the Log4cxx > website > < > https://github.com/apache/logging-log4cxx/commit/39eba952aeca92a3e9d69790fdb789cc864ce133 > >. > Judging from our experience with Log4j, I’d like to share a word of > caution: this can easily become a very slippery slope. > > There are simply too many configuration variables involved (OS, > architecture, version, configuration, etc.), and the codebase itself is > constantly evolving. To give a concrete example: Log4j once had a > performance page with benchmark results collected by Remko, but no one was > ever able to reproduce the same numbers again. Over time, that page became > not only misleading but also a maintenance liability. > > If I may, I'd suggest one of the following approaches, in order of personal > preference: > > 1. Don't do it. It is deprecated before it is released. Keeping it > updated is a liability. > 2. Share your configuration in detail (OS, architecture, version, and > configuration) and provide a script where users can generate these > reports > for their particular setup. > 3. Implement a continuous performance test bed, where option #2 is > _automatically_ (through CI?) got executed for every Log4cxx release. > (This > I wanted to implement for Log4j, but could not secure funding for. > Lucene > has one. <https://benchmarks.mikemccandless.com/>) > > Kind regards. >
