Re: synchronized code

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