you're right, my mistake
On Wed, 2003-01-08 at 21:19, Barry Lind wrote:
> Felipe,
>
> Actually in many cases the size of the EXECUTE may be much larger than
> the PREPARE. It all depends on the number, type and size of your bind
> variables. It is very easy to have bytea or text bind variables that
> are many times larger than the original query. It all depends on what
> you are doing.
>
> --Barry
>
> 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?
> >
> > 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