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:48:50 GMT
Sorry,

The "relative positions" cleanup is a subject of a separate JIRA issue
[1]. May be I should also notice a cleanup [2] which has no direct
relation to ByteStream (BTW, a better name is welcome). The
optimization income of HARMONY-5529 is alike of passing a reference to
the underlying buffer. We have entry stream (ByteArrayInputStream)
wrapped into (JarFileInputStream extends FilterStream) for entry
verification purposes. The patch suggests returning an original stream
if no verification is required. Currently this just removes some
overhead, but potentially may open further ByteStream-like
optimizations of the entry input stream.

[1] http://issues.apache.org/jira/browse/HARMONY-4569
[2] http://issues.apache.org/jira/browse/HARMONY-5529

On Thu, Mar 13, 2008 at 6:36 PM, Alexei Fedotov
<alexei.fedotov@gmail.com> wrote:
> 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,
>  Alexei
>



-- 
With best regards,
Alexei

Mime
View raw message