Re: ORO performance tuning efforts

["Daniel F. Savarese" <df...@savarese.org>]

In message <00...@brutesquadlabs.com>, "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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>