On Jan 31, 2005, at 12:33 PM, Elias Ross wrote:
On Sat, 2005-01-29 at 01:34, Curt Arnold wrote:
How would my patch break the build or their build?
Assuming I don't change any existing code, only add new classes and methods, this wouldn't force any changes on this other projects.
I've admitted that I have not had chance to review your code. Even if it were totally isolated and would not affect existing users (which I would still need to confirm), there is still effort required that the files contain the appropriate license notices, have unit tests, etc. Basically code doesn't go in until a committer has reviewed it and we are all finite beings typically working on our own time. We are grateful for the effort behind your contributions, but the fact we haven't reviewed and integrated it within a week or two of submission doesn't bother me.
Currently all our performance tests are single threaded. In this case,
we need a mock multithreaded application that will dispatch log
messages to identify contentions. There are a variety of tools that
can be used to collect and analyze the system under test, but you need
to frame the benchmark problem first.
I included a mock application to perform some simple benchmarking with my patch, did you not see it? This is how I measured the large amount of contention in the current 1.3 code base. It also showed about a 10% increase in performance on multi-processor machines.
I thought that there was some concern that your sample application was not representative. So maybe the first step is to review your mock application instead of writing one.
Sorry, "getSequenceCount" was a short-hand reference to a fairly
involved thread about a month ago. A sequence number is currently
being used as a logging event identifier, but there are likely better
ways of meeting the actual requirements. The thread is pretty long and
convoluted, most of it was trying to figure out what the actual
requirements were. Having a monotonically increasing message sequence
number wasn't one of them. Having an implementation of equals and
hasCode were requirements (from the Chainsaw team).
I don't see why the Chainsaw team is causing grief for you. If their particular application requires "equals" and "hashCode", they can implement their own wrappers as appropriate for logging events.
It appears their requirements are negatively impacting the base architecture of log4j. I'm sure there is a reasonable compromise to be made.
At this point, they have expressed their preference to have equals and hashCode with value semantics and have code that depends its presence. At this point, I do not have compelling evidence that it is a bad thing and its best to proceed under the assumption that they knew their requirements. Adding wrappers to Chainsaw would cause an increase in total complexity by removing some complexity from the log4j core but adding more in Chainsaw.
Sounds like the "Doctor. it hurts me when I do this" joke. There are certain operations (like retrieving location information) that are known to be expensive. log4j provides mechanisms to get the info if you really want it. The cost is high, but avoidable.
Did you look at the code? ThrowableInformation.extractStringRep is called when you do
Logger.debug("", new Throwable());
And you expect that to be a high frequency call? Exception handling code is expensive in general and should only occur rarely. Obviously everything should be as fast as possible, but the priority has to be on optimizing the high-frequency cases. If you are seeing 20% of your time in spent in logging exception stack traces, then it likely that another 20% is spent in the overhead of raising and catching exceptions. If this was a real application, I would serious look at your use of exceptions. If this was a mock application, I'd be concerned that it isn't representative of actual use.
Is there any particular reason why for JDK 1.4 reflection is used to print the stack trace?
Someone else will have to answer that.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
