This is not really true these days. Dynamic class instrumentation/
byte modification can remove the calls entirely (for loggers not
enabled). They can be enabled during startup (or a reload from a
different class loader).
See the paper at http://www.springerlink.com/content/ur00014m03275421
On Jan 9, 2009, at 1:05 PM, Yonik Seeley (JIRA) wrote:
[ https://issues.apache.org/jira/browse/LUCENE-1482?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel&focusedCommentId=12662476#action_12662476 ]
Yonik Seeley commented on LUCENE-1482:
--------------------------------------
I'm not arguing for or against SLF4J at this point, but simply
pointing out that I didn't think it was appropriate to base any
analysis on the NOP adapter, which can't be used for any project
already using SLF4J.
I think using a logger to replace the infostream stuff is probably
acceptable. What I personally don't want to see happen is
instrumentation creep/bloat, where debugging statements slowly make
their way all throughout Lucene.
bq. Because I seriously don't understand why you think that
checking if debug is enabled can pose any performance hit, even
when used with a real logger.
I've tried to explain - these calls can be costly if used in the
wrong place, esp on the wrong processor architectures. What
appears in inner loop will vary widely by application, and there
are a *ton* of lucene users out there using it in all sorts of ways
we can't imagine. For example, I'd rather not see debugging in
Query/Weight/Scorer classes - for most applications, query and
weight construction won't be a bottleneck, but there are some where
it could be (running thousands of stored queries against each
incoming document via memoryindex for example).
Replace infoSteram by a logging framework (SLF4J)
-------------------------------------------------
Key: LUCENE-1482
URL: https://issues.apache.org/jira/browse/
LUCENE-1482
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Shai Erera
Fix For: 2.4.1, 2.9
Attachments: LUCENE-1482-2.patch, LUCENE-1482.patch, slf4j-
api-1.5.6.jar, slf4j-nop-1.5.6.jar
Lucene makes use of infoStream to output messages in its indexing
code only. For debugging purposes, when the search application is
run on the customer side, getting messages from other code flows,
like search, query parsing, analysis etc can be extremely useful.
There are two main problems with infoStream today:
1. It is owned by IndexWriter, so if I want to add logging
capabilities to other classes I need to either expose an API or
propagate infoStream to all classes (see for example
DocumentsWriter, which receives its infoStream instance from
IndexWriter).
2. I can either turn debugging on or off, for the entire code.
Introducing a logging framework can allow each class to control
its logging independently, and more importantly, allows the
application to turn on logging for only specific areas in the code
(i.e., org.apache.lucene.index.*).
I've investigated SLF4J (stands for Simple Logging Facade for
Java) which is, as it names states, a facade over different
logging frameworks. As such, you can include the slf4j.jar in your
application, and it recognizes at deploy time what is the actual
logging framework you'd like to use. SLF4J comes with several
adapters for Java logging, Log4j and others. If you know your
application uses Java logging, simply drop slf4j.jar and slf4j-
jdk14.jar in your classpath, and your logging statements will use
Java logging underneath the covers.
This makes the logging code very simple. For a class A the logger
will be instantiated like this:
public class A {
private static final logger = LoggerFactory.getLogger(A.class);
}
And will later be used like this:
public class A {
private static final logger = LoggerFactory.getLogger(A.class);
public void foo() {
if (logger.isDebugEnabled()) {
logger.debug("message");
}
}
}
That's all !
Checking for isDebugEnabled is very quick, at least using the
JDK14 adapter (but I assume it's fast also over other logging
frameworks).
The important thing is, every class controls its own logger. Not
all classes have to output logging messages, and we can improve
Lucene's logging gradually, w/o changing the API, by adding more
logging messages to interesting classes.
I will submit a patch shortly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
