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
>>
