db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohamed Nufail <nufai...@gmail.com>
Subject Re: Code coverage for client.net package
Date Sat, 26 May 2012 14:16:09 GMT
On Sat, May 26, 2012 at 1:42 AM, Knut Anders Hatlen
<knut.hatlen@oracle.com>wrote:

> Mohamed Nufail <nufail56@gmail.com> writes:
>
> Hi Nufail,
>
> Thanks for sharing your analysis.
>
> I think you're right that the extra functionality provided by
> PublicBufferOutputStream isn't needed for writeUDT() to function
> correctly.
>
> One small advantage of using PublicBufferOutputStream is that
> PublicBufferOutputStream.getBuffer() returns the buffer directly,
> whereas ByteArrayOutputStream.toByteArray() creates a copy of the
> internal buffer. So by using PublicBufferOutputStream we save one
> allocation of a byte array per write. I would guess this was also the
> motivation for using DynamicByteArrayOutputStream instead of
> ByteArrayOutputStream in the first place.
>
> It's probably not a big deal, but for applications that write many UDTs,
> using PublicBufferOutputStream and accessing the buffer directly might
> take some load off the garbage collector and perform a little better.
>

Yes, that would be a good reason to go with PublicBufferOutputStream.

So making it a stand alone class and using it instead of InputStreamUtil
and DynamicByteArrayOutputStream classes should solve the problem. Shall I
continue with this solution?


>
> --
> Knut Anders
>



-- 

Mohamed Nufail
Undergraduate,
Department of Computer Science & Engineering,
University of Moratuwa.
Blog: http://www.nufailm.blogspot.com/

Mime
View raw message