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?
On Wed, 2003-01-08 at 18:16, Michael Paesold wrote:
> Felipe Schnack <felipes@ritterdosreis.br> wrote:
>
> > Is... but what got better with JVM 1.4 was synch'ing not object
> > creation, so you're basically saying I'm correct? :-)
>
> I think it depends on the virtual machine, but I'm no expert.
>
> I just had a look at the latest StringBuffer sources. What setLength(0)
> does, is to wipe the whole buffer with null-bytes ('\0') in a loop! Although
> I have no idea why it is done, it seems to be very inefficient. Especially
> when you think of the fact, that this single StringBuffer will grow,
> everytime a bigger string is put into it. It seams that sb.delete(0,
> sb.length); is much more efficient. It just resets the internal length
> counter?
>
> Any comments?
>
> Regards,
> Michael Paesold
>
--
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