I agree that something isn't scaling too well. Sync works ok with
directories < 1 GB ( ~17 000 files, 1300 folders) less than a minute..
There are ~ 500 000 (half a million) files, and ~74 000 folders.
When I browsed the sync / copy code I found that there was a lot of
synchronized code blocks. I
On Jan 25, 2008 1:02 AM, Antti Luoma <[EMAIL PROTECTED]> wrote:
> BTW, very large in this case means ~17 GB :)
Well, transferring 17GB @ 100Mb/s takes in theory 1350 seconds (less
than 23 minutes).
You indicated a total time for the sync of 56667816 seconds, which is
about 300 bytes / seconds.
E
BTW, very large in this case means ~17 GB :)
--
-Antti-
2008/1/25, Antti Luoma <[EMAIL PROTECTED]>:
>
> Hi,
>
> I did take a look from sources and noticed the basic java File API, I
> think there might be some optimization (like getting rid of unnecessary
> vector creation). Also caching src fold
Hi,
I did take a look from sources and noticed the basic java File API, I think
there might be some optimization (like getting rid of unnecessary vector
creation). Also caching src folder contents (is maybe storing contenst to
outputstream directly and reading from there) might improve it? This of
On Jan 24, 2008 3:53 AM, Antti Luoma <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am using ant 1.7.0 task to sync 2 very large directories. It
> currently takes too much time to do this (to be usable).
Sorry Antti, but there's no free lunch. Either you want to sync, in
which case you need to scan both
Have you looked at rsync?
Antti Luoma <[EMAIL PROTECTED]> wrote: Hi,
I am using ant 1.7.0 task to sync 2 very large directories. It
currently takes too much time to do this (to be usable).
Here is the target that I run.
I invoked it whit build metrics listener and the outp
Hi,
I am using ant 1.7.0 task to sync 2 very large directories. It
currently takes too much time to do this (to be usable).
Here is the target that I run.
I invoked it whit build metrics listener and the output that I (finally) got
was:
[sync] Removed 1 dangling direc
