ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 62995] Unzip performance regression on Windows due to BZ 62502
Date Mon, 10 Dec 2018 07:24:55 GMT
https://bz.apache.org/bugzilla/show_bug.cgi?id=62995

Jaikiran Pai <jaikiran@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|                            |All

--- Comment #1 from Jaikiran Pai <jaikiran@apache.org> ---
Hello Falko,

Is this target using "unzip" in just a basic manner or is there anything more
to it? If possible, can you attach that target.

>> I guess the problem is the use of File.getCanoniocalPath() (twice for each file being
extracted)

Looking at the code in question (the one which calls the
FileUtils.isLeadingPath()), the "dir" will always be same destination
directory. So even if we end up calling getCanonicalPath twice, I would expect
the JRE implementation to return a cached value (as far as I remember, 1.8.x
latest version of Java still uses canonical path cache). So I think, it
shouldn't be that expensive (relatively). However, I'm not stating that this
isn't the cause and you probably are right that this change ended up being
expensive.

>> Unfortunately I am not allowed to share the JBoss EAP 6.4 zipfile I was testing with
(a RedHat subscription is required).
The file is around 300 MB and cotains 1340 directories and 1517 files.

Can you post the timings though, with 1.9.12 and 1.9.13? That will give us some
idea on what kind of performance regression we are seeing. In the meantime,
I'll see if I can reproduce this on a *nix with a similar large file.

-- 
You are receiving this mail because:
You are the assignee for the bug.
Mime
View raw message