ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From testn <te...@doramail.com>
Subject Re: ivy:retrieve performance
Date Thu, 14 Jun 2007 15:26:35 GMT

Hanin,

I just found the problem. My setting accidentally contains
checkUpToDate="false". That's why it tries to copy the file every time. I
will close down the issue. 

Thanks,


testn wrote:
> 
> It actually happens with both sync="true" and sync="false". The files are
> copied every time but the modified timestamp will be reset to the original
> timestamp in .ivy folder.
> 
> 
> 
> Xavier Hanin wrote:
>> 
>> On 6/14/07, testn <test1@doramail.com> wrote:
>>>
>>>
>>> Hi Hanin,
>>>
>>> I'm pretty sure. I fired up filemon to check it. I use <ivy:retrieve
>>> sync="true" /> and it seems to copy all the file everytime.
>>>
>>> 10:11:55 AM     java.exe:6380   READ
>>> C:\workspace\repo\.ivy\cache\org.springframework\spring-core\jars\spring-
>>> core-2.0.3.jar
>>> SUCCESS Offset: 163840 Length: 8192
>>> 10:11:55 AM     java.exe:6380   WRITE
>>> C:\workspace\mystuff\lib\spring-core-2.0.3.jar  SUCCESS Offset: 163840
>>> Length: 8192
>>>
>>> Does it have anything to do if I don't have md5 and sha1 files?
>> 
>> 
>> No, it shouldn't. It seems to be a bug so. Which version of Ivy do you
>> use?
>> Could you open a JIRA issue?
>> 
>> Xavier
>> 
>> Thanks
>>>
>>>
>>>
>>> Xavier Hanin wrote:
>>> >
>>> > On 6/14/07, Gilles Scokart <gscokart@gmail.com> wrote:
>>> >>
>>> >> > 2. The buffer in FileUtils.java is too small. It's set at 8192.
It
>>> >> seems
>>> >> > to
>>> >> > > be much better for me to set it much larger. This is due to
the
>>> fact
>>> >> > that
>>> >> > > it
>>> >> > > needs to read and write simultaneously. The bigger the buffer
is,
>>> the
>>> >> > > smaller number of time, HD header has to move. For me, 65536
>>> seems
>>> to
>>> >> > > perform much better but I haven't tried other numbers.
>>> >> >
>>> >> >
>>> >> > I'd like to get more feedback on this. One use case is not the
>>> other.
>>> >> This
>>> >> > size has been borrowed from Ant copy mechanism. Maybe what we could
>>> do
>>> >> is
>>> >> > make this configurable, so that one could adapt to its needs. Or
>>> try
>>> to
>>> >> > guess a good size depending on the size (when it's possible to
get
>>> an
>>> >> idea
>>> >> > of the size before copying).
>>> >> >
>>> >> > Xavier
>>> >> >
>>> >>
>>> >>
>>> >> Couldn't we use the nio for that?  (See
>>> >> http://www.javalobby.org/java/forums/t17036.html)
>>> >
>>> >
>>> > According to comments 10 and 11 NIO have bad performance for large
>>> files
>>> > on
>>> > linux, and input stream with byte buffer is pretty close to NIO for
>>> small
>>> > files (see comment 13 conclusion). So I'm not sure switching to NIO
>>> would
>>> > indeed help a lot. According to the tests in the thread you pointed
>>> using
>>> > a
>>> > 64kB buffer seems to be a good choice (which confirms  testn tests),
>>> at
>>> > least for large files. OTOH the last conclusion (comment 17) is
>>> different.
>>> > So I don't really know what to think about that. We should make some
>>> tests
>>> > on several platforms and jvms to draw conclusion ourself, but it takes
>>> > time.
>>> >
>>> >
>>> > Xavier
>>> >
>>> > Gilles
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Xavier Hanin - Independent Java Consultant
>>> > Manage your dependencies with Ivy!
>>> > http://incubator.apache.org/ivy/
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/ivy%3Aretrieve-performance-tf3907253.html#a11121249
>>> Sent from the ivy-user mailing list archive at Nabble.com.
>>>
>>>
>> 
>> 
>> -- 
>> Xavier Hanin - Independent Java Consultant
>> Manage your dependencies with Ivy!
>> http://incubator.apache.org/ivy/
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/ivy%3Aretrieve-performance-tf3907253.html#a11121635
Sent from the ivy-user mailing list archive at Nabble.com.


Mime
View raw message