DO NOT REPLY [Bug 48778] LogMF performs slower than SLF4J in benchmark

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=48778

--- Comment #2 from Curt Arnold <ca...@apache.org> 2010-03-14 01:50:00 UTC ---
The performance different does appear to be specific to requests that contain
either a Number or a Date as a parameter.

The bottleneck fragment  was:

                    if (arg0 instanceof String) {
                        replacement = arg0.toString();
                    } else if (arg0 instanceof Number) {
                        replacement = NumberFormat.getInstance().format(arg0);
                    } else if (arg0 instanceof Date) {
                        replacement = DateFormat.getDateTimeInstance(
                                DateFormat.SHORT,
                                DateFormat.SHORT).format(arg0);
                    } else {
                        replacement = String.valueOf(arg0);
                    }

If the formatted value was a Integer, the call to NumberFormat.getInstance()
took 75% of the time in format(), while NumberFormat.format() took 16%.  All
the other code in this section was negligible.

Caching the result from NumberFormat.getInstance() eliminated the per-call hit
for NumberFormat.getInstance() though it is still expensive the first time the
formatter is obtained without any detectable per-call hit for the
synchronization.

The call to NumberFormat.format() is roughly 5 times more expensive than the
functionally equivalent call to String.valueOf().  The functions appear to
return the same string for smaller integers, however they return different
formatted values for doubles.  The committed code uses the cached NumberFormat
if the parameter is a double or float and falls through to String.valueOf() for
the other number types.  It is possible this results in LogMF not returning
exactly the same formatted string as MessageFormat for some values or for some
locales, but it seems like a reasonable optimization.

Date's had a similar performance profile, the call to
DateFormat.getDateTimeInstance() was 85% of time in format(), 12% of time was
spent in DateFormat.format().  String.valueOf() does not return the same value
as DateFormat or MessageFormatter, so any date type is handled by DateFormat. 

When recreated the original benchmark report before the changes, I got:

LogMF (old): 3632
LogMF (new): 501 
SLF4J: 748
LogSF: 720

Replacing Integer x with String x:

LogMF (old): 321
LogMF (new): 272
SLF4J: 510
LogSF: 628

Replacing Integer x with Date x:

LogMF (old): 7212
LogMF (new): 2340
SLF4J: 834
LogSF: 1067

Replacing Integer x with Double x:

LogMF (old): 4585
LogMF (new): 1232
SLF4J: 1001
LogSF: 567


new = rev 922699
old = rev 922698


While there are other enhancements I expect to do on LogMF and LogSF shortly,
caching NumberFormats and DateFormats gets LogMF comparable to SLF4J except for
dates and doubles which should be rare enough that the hit is tolerable.  If it
isn't, you can always use LogSF for those calls.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org