Alexei Fedotov wrote:
Let me write something more understandable. Breathe, Alexei, breathe slowly.
Code is good ;-)
1. Our native code returns us Zip entries in a form of a byte array
which is later wrapped in ByteArrayInputSteam object.
So this is my point. While I see that you are writing the ByteStream
util to reach into a regular ByteArrayInputStream to get the backing
array -- my question is why not change the
ZipFile#getInputStream(ZipEntry) implementation to return a ByteStream
(which will be a subclass of ByteArrayInputStream that will simply
return the backing array when asked without reflection).
I agree with the rest of the arguments below.
Regards,
Tim
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 <[EMAIL PROTECTED]> 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
