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 18:07:21 GMT
There are also some ideas around the picture frame which coud give
more perception why a number of bugs in the code is the same, why I do
not rush with further changes, etc.

1. I choose evolutionary approach because rewriting the whole thing
would make me responsible for strange limitations it has, and removing
all limitations would make the implementation slower and harder to
understand. It's hard to judge which limitations are natural and which
are not. Also it would take a good amount of time writing tests to
understand and compare against limitations of our competitors.

2. I asked a guy who learned TPTP to get Eclipse startup profile for
me. Having this profile would help to decide which of  many TODO are
most worthy to be fixed.

Thanks.

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



-- 
With best regards,
Alexei

Mime
View raw message