[slf4j-dev] [Bug 116] Switching the log message format to that of java.util.Formatter

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=116


Ceki Gulcu <listid at qos.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |listid at qos.ch




--- Comment #23 from Ceki Gulcu <listid at qos.ch>  2008-12-03 22:16:14 ---
(In reply to comment #22)
> I don't think it matters. The new formatter is certainly going to be slower
> than the existing one. But the idea is to only use it where it is needed. The
> proposed way of doing that is via having a unique logger factory. That is
> really where I have an issue. The main logger factory should be able to return
> an XLogger or some other type of logger. This could be handled via
> configuration or annotations or a "marker" on the getLogger call. Creating new
> Logger factories for each extension isn't the right answer.

I don't see org.slf4j.LoggerFactory evolving. However,
org.slf4j.ext.XLoggerFactory is another matter. It could indeed be modified to
return different XLogger implementations, possibly based on annotations.

Returning to the main point, dynamically determining which formatting style is
in use is likely to have an impact on performance.

> I would also love to see concrete tests comparing logging 10,000 records to a
> file using the current formatter vs the enhanced formatter. If the I/O overhead
> makes the difference minor than it might not even be a problem to have it be
> the default formatter.

The java.text.MessageFormat is approx. 10 times slower than the SLF4J
formatter. When you write to a file, (thus taking I/O into account), j.t.Format
*doubles* the time it takes to log. Hard to believe but true.


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