Re: [log4cxx] Performance graphs

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.
>