Oliver,
What you need to be testing is syncronization vs. object allocation
*and* garbage collection. How are you testing the overhead that the
garbage collection adds since garbage collection in java by its nature
is something that is async.
Perhaps having a System.gc() call at the end of each test would be
sufficient?
thanks,
--Barry
Oliver Jowett wrote:
> On Wed, Jan 08, 2003 at 07:11:46PM -0200, Felipe Schnack wrote:
>
>> yuck! I think this implementation is kinda gross (can you send me this
>>source? Just curious). Just imagine using preparedstatements, you will
>>allocate a big internal buffer (to store the "PREPARE", etc command) and
>>then just execute much smaller "EXECUTE" calls.
>> Well, what we have to decide is what is better:
>> - Create and destroy StringBuffer objects. This adds object creation
>>overhead (as far as I know this isn't a problem) and gc overhead (I have
>>no idea if it's costly)
>> - Continue the way it is, or: use a unique StringBuffer, that is
>>synchronized in every use (maybe it's better now, but historically a
>>costly operation, AFAIK) and have its contents reset every time (IMHO a
>>bad programming pratice - easily someone will forget to do it - and as
>>pointed out by Michael, not very effective).
>> My opinion is quite clear, isn't it?
>
>
> I'm in the process of benchmarking this at the moment (we have similar
> decisions to make in our own project). At this point, using a 1.4.0 VM on
> Solaris 8, it looks like object allocation is faster than synchronization
> with:
>
> - 1 cpu + server VM + lock contention
> - >1 cpu + server VM
> - client VM
>
> Synchronization is slightly (5%) faster for 1 cpu + server VM + no lock
> contention.
>
> Actual numbers to follow when I'm done.
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>