The contents of my last message were not completely accurate. Since StringMatchFilter invokes the String.indexOf() method, chaining one or more StringMatchFilter instances will have a measurable impact on performance. However, it should be trivial to devise a filter similar to StringMatchFilter but based on String.equals(). Such a filter would have zero or near zero impact on performance for the case being discussed. More below.
At 07:22 AM 1/6/2005, Kevin A. Burton wrote:
Ceki G�lc� wrote:
I'd expect the CPU hit to be minimal because the filter chain will only be applied on enabled log statements. For the vast majority of events the filter will not match. In the case of two unequal string, string comparison returns very quickly. I'd go as far as speculating that the CPU hit would be beyond the measurable.
Whats the status of this patch? Was it accepted?
Yes, it was accepted but expect it to be enhanced as suggested earlier.
I'm not prepared to do all this extra work because honestly I don't need it for my app.
Are you saying that losing the context of the surrounding log messages is not a concern in your particular use-case? My intuition tells me that having the stack trace for a specific call plus all the surrounding log messages would be very useful.
Kevin
--
-- Ceki G�lc�
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
