Re: Dired C idea

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

>>   > Should be feasible. The hard part is a rule to determine, whether rsync
>>   > is better suited than the existing implementation, with the given actual
>>   > arguments. I suspect, that small directories and/or short files are
>>   > better served with the current implementation.
>>
>> Do we really need to decide this?  Wouldn't it be ok to use rsync
>> for all cases (where Tramp is not in use)?
>
> I would like to see some benchmark figures first. For example, I'm not
> sure that rsync performs better when the target directory does not exist
> yet, and there's nothing to sync.

I made some comparison between "cp -pr" and "rsync -pr" on shell
level. I've copied the whole Emacs tree to somewhere else. First the
case, that the target does not exist:

$ time cp -pr ~/src/emacs /tmp/emacs.cp
0.086u 1.322s 0:04.43 31.6%     0+0k 1817688+0io 1pf+0w

$ time rsync -pr ~/src/emacs /tmp/emacs.rsync
5.776u 2.069s 0:05.76 135.9%    0+0k 1384384+0io 1pf+0w

"rsync -pr" is slower than "cp -pr". Now I've applied the rsync command
again, to the unchanged directory tree with exisiting target:

$ time rsync -pr ~/src/emacs /tmp/emacs.rsync
6.116u 2.457s 0:06.63 129.1%    0+0k 1069632+0io 4pf+0w

It is even a little bit slower than the first rsync run. So I don't
know, whether there is really a performance boost when we use rsync for
local directory copies.

OTOH, `copy-directory' in files.el runs recursively `copy-file',
file-wise. Perhaps we could improve this implementation on C level.

Best regards, Michael.