Old version: 5.20150916-1 New version: 5.20151208-1
I have noticed that with the addition of the progress display, the actual overall performance of the transfer drop very noticeably from these two versions. I am very tempted to keep the old version around to just handle the transfers.
Also, I decided to build a newer version from git, using debuild. I noticed that the libghc-persistant dependencies have no trailing commas. I added the commas, built the package and had two errors in one of the tests. I removed these dependencies from the control file and I am currently performing a rebuild (they were not present in 12/08 version).
Build complete. Tests passed. Parallel transfers seem to be back up to speed. Thanks!
I have been getting more failures than I used to when using -J with get and copy commands.
The dirannex remote is a local directory remote.
Version 5.20151019 is right between the two versions given, and probably contains the reason for the drop in performance: That version started checksumming files after receiving them to verify that their content is good.
If so, this will get back the old level of performance:
If the performance problem were actually related to the new progress display, passing --quiet will disable that display. If you can show that simply passing --quiet speeds up transfers significantly somehow, I'd be happy to investigate further.
@umeboshi I don't think your comment is really related to the original question. If you run gets of a bunch of files in parallel, and two of the files have the same content, you can get this situation where a transfer of the content is already in progress.