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 15:36:03 GMT
Let me write something more understandable. Breathe, Alexei, breathe slowly.

1. Our native code returns us Zip entries in a form of a byte array
which is later wrapped in ByteArrayInputSteam object.
2. Instead of copying portions of this ByteArrayInputSteam via
read(buffer) call it is quicker to get a reference to the underlying
buffer using reflection and work with this array.
3. This big buffer is useful for further manifest verification. This
is a subject of separate [1]. Instead of copying manifest sections
into smaller byte buffers, we maintain a list of relative positions in
the big buffer, and update the digests using these positions.
Generally, storing two relative positions is much cheaper than
allocating memory and populating it with bytes. That is why I refer to
this change as to implementation cleanup, and not an optimization.
4.  I wrote ideas of possible further cleanup in TODO comments. They
could be described as follows: I removed two of six copies (acts of
copying) of a manifest byte before it becomes accessible as a key or
value in a java hash table. Another two copies are easy to be removed,
so there is enough place for improvement here.

If we would only know the algorithm which will be used for digesting,
we may replace a manifest buffer with few signatures which might be
updated while manifest is read. After algorithm is known the manifest
may be verified in one pass.

On Thu, Mar 13, 2008 at 6:03 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Alexei Fedotov wrote:
>  > 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.
>  Yep, I see that.  Now how will you use it (i.e. can you show the code
>  that references ByteStream)?  I can see where you are going but want to
>  see the whole picture.
>  Regards,
>  Tim

With best regards,

View raw message