harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [classlib][luni] optimized InputStream reader (HARMONY-5522)
Date Thu, 13 Mar 2008 14:48:02 GMT
I see the question. The general InoouttStream cannot be optimized, but
our implementation returns ByteArrayInputStream. We can choose a fast
path without using arraycopy  if we are first to read from this
ByteArrayInputStream object. We just get get a reference to the
underlying buffer and return it without copying the contents. This
works only for unmodified ByteArrayInputStream object, but this is
exactly our case.


On Thu, Mar 13, 2008 at 5:33 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > Alexei Fedotov commented on HARMONY-5522:
>  > -----------------------------------------
>  >
>  > Tim,
>  > LBAInputStream is an unfinished prototype and is not ready to be
>  > committed. ByteStream.java should be committed instead. I have discussed
>  > ByteStream related limitations on the list [1], and failed to keep the
>  > JIRA updated. I suggested that once we would like to get rid of
>  > ByteStream limitations, we might want to finalize LBAInputStream
>   >
>  > [1] http://markmail.org/message/vak2ewyckvtoxk3q
>  Yeah, I read that post, but what I'm missing is the proposed use you
>  will make of the ByteStream (or LBAInputStream).
>  I see the general idea of optimizing the retrieval of bytes from the
>  InputStream, but wonder if we can do better than grabbing them all then
>  doing a System#arraycopy (in ByteStream#readFully).
>  Can you paint the next part of the picture for me?
>  Regards,
>  Tim

With best regards,

View raw message