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