Mailing-List: contact notifications-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ant.apache.org
Date: Thu, 16 Aug 2012 03:36:38 +1100 (NCT)
From: =?utf-8?Q?Nicolas_Lalev=C3=A9e_=28JIRA=29?= <jira@apache.org>
To: notifications@ant.apache.org
Message-ID: <2018718158.14419.1345048598057.JavaMail.jiratomcat@arcas>
In-Reply-To: 
 <1775447081.1933.1317609394132.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (IVY-1318) Faster symlink creation (avoid a JVM
 fork per symlink)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/IVY-1318?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

Nicolas Lalev=C3=A9e updated IVY-1318:
---------------------------------

    Attachment: IVY-1318-r1373520.patch

patch rebased on the current trunk.
               =20
> Faster symlink creation (avoid a JVM fork per symlink)
> ------------------------------------------------------
>
>                 Key: IVY-1318
>                 URL: https://issues.apache.org/jira/browse/IVY-1318
>             Project: Ivy
>          Issue Type: New Feature
>          Components: Core
>    Affects Versions: 2.2.0
>            Reporter: Oliver Jowett
>            Priority: Minor
>              Labels: patch
>         Attachments: IVY-1318-r1373520.patch, ivy-2.2.0-symlink.txt
>
>
> We have a large project using Ivy with many large artifacts.
> In theory we should benefit from symlink=3D"true" (space savings and redu=
ced I/O), but in practice the overhead of forking the Ant JVM for each indi=
vidual symlink means that a build using symlink=3D"true" actually runs a lo=
t (30%+) slower, which is too much of a cost to justify using it.
> To work around this I modified FileUtils to run a single long-lived shell=
 process that reads instructions from stdin and performs symlinks according=
ly.
> This makes symlink=3D"true" no slower than symlink=3D"false".
> I will attach a patch against 2.2.0. Tested only in a Linux environment, =
but in theory it should work on anything POSIX-y, and should fall back to f=
ile copy much as the existing code does if anything goes wrong.
> Any interest in getting this included in an official version?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira