On Dec 11, 2008, at 9:04 AM, Ceki Gulcu wrote:
On Dec 9th 2008 16:57 GMT Curt Arnold wrote:
> The supposed performance benefit of the SLF4J formatter over the
> java.text.MessageFormat only occurs when you compare the performance
> against naive use of java.text.MessageFormat. LogMF handles the
> simplest pattern specifications (those just involving {0}, {1}, etc)
> internally and only delegates to java.text.MessageFormat for more
> complex pattern specifications, resulting in equivalent
performance to
> the SLF4J formatter on functionally equivalent format specifiers
while
> still supporting the full java.text.MessageFormat capabilities.
On Dec 11th 2008 08:21 GMT Curt Arnold wrote:
As I remember, my benchmarks were very, very low overhead logging
calls (NullAppender or the like) or less than threshold logging
calls and the performance between the formatters was totally lost
in the NullAppender overhead. It was several years ago, so I'll
have to dig in the archives.
There is no point in digging into into the archives. Unless you can
point to a mistake in the test case I provided yesterday, it
irrefutably demonstrates that LogMF does not offer equivalent
performance.
You are using a private method in a totally artificial manner and no
comparison with the overhead of creating a LoggingEvent etc. Maybe
outside the context of a logging request the performance difference
was significant, but the performance difference could be dwarfed by
the expense of creating a LoggingEvent or some other fixed cost.
Recognizing performance advantage of the SLF4J formatter would have
been a welcome change. At the very least you should stop referring to
the "supposed" or "alleged" performance benefits of the SLF4J
formatter. Moreover, in the future, you should refrain from making
incorrect statements with such self-confidence and certainty and later
weasel yourself out of them by minimizing their importance.
I will explain why I've not been fully involved in this thread in very
short order. Please realize that I spent a large amount of time on
this list several years ago discussing with the community and provided
many benchmarks at that time. I recall it did not show any detectable
difference due to SLF4J-style format and MessageFormat in the context
of either a trivial appender or a lower than threshold request. Maybe
there very well could be a slight difference in performance of the
formatter, but if it is dwarfed by other unavoidable costs (creation
of a LoggingEvent for example), then the relative difference would
never be noticed.
There are many features that java.text.MessageFormat has that the
SLF4J formatter does not have. Even if there is a substantial
performance difference, there may be cases where you would want to use
MessageFormat or java.util.Formatter in spite of performance
differences. The LogMF and LogSF approach allows users to pick which
formatter best suits their needs. The SLF4J approach enforces a
choice of a particular formatter over any other formatter.
As for Jorg who does like message formatting, he is obviously entitled
to his opinion. However, as log4j committers, out job is to respond to
user demand. While several years ago one could reasonably argue that
SLF4J was not a mature and stable API, that argument is no longer
valid. Not only is the SLF4J API stable and mature, it is also very
popular. By adopting the SLF4J API natively, the log4j community would
do the larger java developer community an immense service by
disambiguating java logging. I don't think that half-hearted attempts
such as the "extras companion" help, on the contrary. Java logging
does not need more choice. On the contrary, it needs consolidation.
The Apache Software Foundation does not control the SLF4J project, but
since when the ASF is about control? There are many Apache projects
which implement specifications drafted outside Apache.
The Apache Software Foundation is about community and collaborative
development first. Projects that ignore community and collaboration
are either chastised by the board or shown the door.
There is a substantial community that depends on log4j 1.x remaining
100% compatible with their existing code that used log4j 1.x features
in the expected and normal way. It is a disservice to them to release
any log4j 1.x that breaks their perfectly valid app. Several years
ago there was not an identified way to directly support SLF4J without
breaking compatibility with any app that used a non-String message and
without making a maintenance release add a dependency on an alpha or
beta jar. Maybe your new proposal addresses the compatibility issue
and SLF4J is fixed, but there has not been any time to prepare an
exploratory project in the sandbox to confirm your suggested approach
and to evaluate the consequences.
In my earlier discussion about the ASF and log4j brand, my intention
was not denigrate your role in founding the project or try to claim
responsibility for your work. It is just that a users expectation
from the Apache and log4j brand is that Apache does not break
compatibility on dot releases and log4j 1.x+1 is compatible with log4j
1.x. There is no expectation that logback, nlog4j, slog4j, log4j 2 or
any other designation is binary and source compatible with log4j 1.x.
There is an expectation that log4j 2 will address locking issues and
use Java 5 idioms. If there is a log4j variant that supports SLF4J
but is not compatible with log4j 1.x, I'd strongly prefer using a
different name but synchronizing the version numbers so that slog4j
1.2.18 would be a variant of log4j 1.2.18 that was mostly log4j
compatible but supported SLF4J. However, all that is labeling issues
for code that we have not seen or written.
You still have commit rights on the ASF SVN. I would strongly object
to you modifying the trunk to experiment since we are very near to a
log4j maintenance release. However, you float a proposal to copy the
trunk into the sandbox and apply your desired modifications and let
the list evaluate your proposal as expressed in concrete code, I'd
vote +1 to allow you to experiment.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
