Interesting information, I just can't understand why in multiprocessor
environments synch'ing is faster. Anyway, I guess would be nice to
benchmark against JDK 1.3... mainly because no arguments using JDK 1.4
will not convince most developers :-)
On Wed, 2003-01-08 at 19:40, 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
--
Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893
Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341
