On Jan 28, 2005, at 6:30 PM, Elias Ross wrote:
On Fri, 2005-01-28 at 11:45, Curt Arnold wrote:
Would it be possible to check in the code as-is and if there is any future interest (or disinterest) incorporate or remove as appropriate?
Sorry, A committer who blindly checked in code they hadn't reviewed would likely not remain a committer for long. Actually, they would more likely get very hostile emails. If anyone in the community is just dying to use your patches, there is nothing to stop them from merging it into their working builds. However, by committing it into the CVS, I'm at least forcing the changes on the 40 projects or so in Gump that build against our nightlies.
I haven't, but I have been following the discussion. I think the initial requirement before considering integrating any of the code is to have a reasonable multi-thread performance test. Then likely we'd look at each aspect in your code along with other queued concurrency related issues like the getSequenceCount issue.
Unfortunately, you can't get much information out of "for loops" and "System.currentTimeMillis()" with respect to thread contention. Usually, you write a class that exercises the code, then exercise that test on a multi-threaded machine, and use a tool that can properly evaluate the contention and time spent in your program.
There are several free programs that can help. Commercial tools are probably ideal, but a proper tool is 10X better for this sort of task than taking in-JVM timings.
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.
Regarding the getSequenceCount, this is what I did for a library I worked on that had messages with sequence numbers:
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).
Again, if you really care about performance or evaluation of theories, you can spend some time (ultimately less time) with profiling tools.
For example, one slow spot I found was:
org.apache.log4j.spi.ThrowableInformation.extractStringRep()
This class iterates through the methods on every Throwable, using quite a lot of CPU (10-20%). This seems like a good feature for 1.3 users, but perhaps unnecessary on JDK 1.4? Plus, most people who implement getCause also have a printStackTrace that does the right thing.
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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
