You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by fl...@tutanota.com.INVALID on 2021/11/11 08:08:14 UTC
[COMPRESS] ZipFile: Using an ArrayList for the entries member
variable whose capacity matches the EOCD total number of entries?
PKWARE-APPNOTE-6.3.9.txt states:
4.3.14 Zip64 end of central directory record
...
total number of entries in the central directory 8 bytes
4.3.16 End of central directory record:
...
total number of entries in the central directory 2 bytes
Yet the list to keep track of those entries in ZipFile is a LinkedList:
private final List<ZipArchiveEntry> entries = new LinkedList<>();
Would it not be more efficient with an ArrayList whose initial capacity matches the total number of entries
stated in the end of directory record? Assuming the total number of entries <= Integer.MAX_VALUE – 8
of course (see https://www.baeldung.com/java-arrays-max-size).
This would also open the way for adding an option to have the ZipFile entry list sorted *in-place*
in physical order, which eliminates the needs to allocate yet another large array in getEntriesInPhysicalOrder when dealing with zip files containing many entries.
--
Sent with Tutanota, the secure & ad-free mailbox.
Re: [COMPRESS] ZipFile: Using an ArrayList for the entries member variable whose capacity matches the EOCD total number of entries?
Posted by Gary Gregory <ga...@gmail.com>.
The best way forward is for you to create a PR on GitHub so we can all see
what this would look like.
Thank you,
Gary
On Thu, Nov 11, 2021, 03:08 <fl...@tutanota.com.invalid>
wrote:
>
> PKWARE-APPNOTE-6.3.9.txt states:
>
> 4.3.14 Zip64 end of central directory record
> ...
> total number of entries in the central directory 8 bytes
>
> 4.3.16 End of central directory record:
> ...
> total number of entries in the central directory 2 bytes
>
> Yet the list to keep track of those entries in ZipFile is a LinkedList:
>
> private final List<ZipArchiveEntry> entries = new LinkedList<>();
>
> Would it not be more efficient with an ArrayList whose initial capacity
> matches the total number of entries
> stated in the end of directory record? Assuming the total number of
> entries <= Integer.MAX_VALUE – 8
> of course (see https://www.baeldung.com/java-arrays-max-size).
>
> This would also open the way for adding an option to have the ZipFile
> entry list sorted *in-place*
> in physical order, which eliminates the needs to allocate yet another
> large array in getEntriesInPhysicalOrder when dealing with zip files
> containing many entries.
>
> --
> Sent with Tutanota, the secure & ad-free mailbox.
>