In message <00b501c29201$30f04330$[EMAIL PROTECTED]>, "Bob Dickinson \(BSL\)" writes: >performance tests. It will probably take a week or so. I'm in the middle >of something right now and I have to rework the tests to require as little >support code as possible (right now they use a bunch of our util stuff that >I'd rather not include and will just complicate things).
I've been out of commission the past week and a half. I'll add the proposed shor-term plan to the documentation tree and get the ball rolling next week. > Regarding the Perl5Repitition object overhead, with one thread it was >negligible (less than 1%, maybe a lot less than that). With 10 threads it >was 40% (about 20% in each place). I didn't verify this outside of the >profiler, and I didn't run the thread profiler to actually see the heap >contention, so I can't swear that the profiler was telling the truth here. It's certainly not implausible. As you indicate next, object creation will really start to drag an application that uses many threads. In the case of Perl5Repetition, the serial garbage collector would also be a source of slow down. >We have definitely run into degenerate object creation performance with high >thread counts (50+) and moderate to high object allocation in our app, since >regardless of the number of processors or threads, Java can only create one Yeah, you can't beat Amdahl's Law. Supposedly the version of HotSpot shipping with J2SE 1.4.1 has parallelized parts of the garbage collection process, but I don't know that object creation is anything but serial. daniel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
