FastCopy vs DO - HUGE difference

Is any chance to speed up copying process? Especially for directories that contains lot of small files.

I made small test using FastCopy and internal DO copy of Mozilla directory (lot of small files, profile backup, old profile etc. - over 600 MB) from fast SSD to RAM disk.

DO was second (so it's not because, for example, cache advantage after first using some directory). These differences was even after second and third try.

FastCopy - 7 seconds
DO - 51 seconds!

I suspect that will be some differences but not that big!

Maybe informations on copy dialog are updated so often?

[quote]FastCopy - 7 seconds
DO - 51 seconds![/quote]

There is something wrong with the way you did your test. :slight_smile:

You are probably not comparing the same operations. If lots of small files are involved, the per-file overhead of copying timestamps, attributes, comments, NTFS metadata, etc. becomes more significant than the data itself. The other program is probably configured not to copy any of that, while Opus is probably configured to copy it.

So, copying these attributes etc. from SSD to RAM should slow down copying that significant?

Yes.

We have a thread like this every few years and it is always a complete waste of everyone's time (not just ours, but yours), so if you think you've found something please be very sure and thoroughly look into all the details first.

Or set what you feel you want to be copied under Preferences / File Operations / Copy Attributes and keep in mind each thing has an overhead, then don't worry about it, as there is usually nothing to be gained. The hardware, operating system, antivirus etc. are generally responsible for file copy speed, while Opus sits waiting for the read/write requests it does to happen.

For large files, Preferences / Miscellaneous / Advanced: copy_nonbufferio_threshold can also be a factor, but using it can also introduce compatibility issues with some poor hardware/drivers/filesystems, so be careful.

Ok, I turned off everything under "Preferences / File Operations / Copy Attributes" and nothing really changes. BUT - I minimize copy dialog while copying and I have the same operation in "only" 32 seconds! 15 seconds FASTER! So as I say - this window update informations take up too much time. It's not just system settings. I think I investigate enough to prove that something is wrong here.

The progress dialog runs on a separate thread to the file copying and updating it is usually negligible on modern hardware.

There have been cases where hardware drivers cause issues here, though. Make sure the graphics and motherboard (SATA etc.) drivers are installed and up to date, since the generic ones can be very slow and bad or generic drivers can cause graphics operations to stall disk operations (or at least could in the past; haven't seen that in over 10 years but it's possible it still happens; it's all going over the PCIe bus).

Processor i5-3470, fast SSD, GeForce 660 and 16GB ram is, in my opinion, modern enough.

I am computer freak, so I always check drivers, hardware, etc. Everything is as fast as can be.

I want to prove that I'm right and I hope is possible at least to investigate problem instead of being sure that there is no problem.

With bad drivers, by the way, FastCopy should be as slow as DO.

BTW. From ramdisk to ramdisk - copy process is the same slow as from SSD to ramdisk. And there is no SATA drivers here. I can show you my ramdisk transfers if you want.

The real solution can be at least trying to investigate problem or maybe (suggestion) change info on dialog every, for example, 0.2 second, not every single file.

I check some old posts on this forum (when I search on google) with similar problem and I found few. Is that difficult to not refresh progress bar if previous change was made less than 1/10 second before? And just try that maybe, just MAYBE, problem is in Opus? I really want to buy best filemanager, not something that I must use with lot of other tools that replaces built-in functions.

And I very like companies that can admit mistakes and errors sometimes. Still have 40 days to tests. I hope I'll can buy product with some important for me bugs fixed.

If you can give us simple, reproducible steps which demonstrate your theory, and involve a real-world situation, then I'll be happy to look into it.

"Reproducible" needs to involve:

  • Copying some known (e.g. C:\Windows) or provided (e.g. via a zip or rar file somewhere) data set.
  • From A to B folders and types of devices
  • using X method (e.g. the Copy Files button, or Drag & Drop).
  • And something else to compare it against (e.g. "progress dialog minimised or not" is fine, if that's what you want use to look at).

"Real world" means:

  • If it affects things people do for real, with a significant impact on day-to-day work due to the extra time it takes every time they do those operations, then it is certainly worth investigating.
  • But if it only happens in a synthetic/pathological situations which would only be tried when looking for problems, like "copy a 1,000,000 zero-byte files from a RAID-0 SSD setup to a RAM disk, and it takes a few more seconds" then it's not worth investigating as it wouldn't be causing anyone real problems and we'd be better spending time improving other areas.

Happy to investigate this if you can give us those things, but I hope you'll also understand I am reluctant to if you can't, as I have literally spent weeks of my life on threads like this which usually end up a waste of time, or making 'fixes' for situations/differences which turned out to be highly dependent on particular machines. (We once spent a long time improving things for one scenario, only to later found it made things worse for many other people and broke things entirely for some. Wasn't worth it.)

I'll try to give you reproducible steps soon.

In my case that was not some synthetic test, but I was really trying to copy profile of Mozilla to ramdisk (for some reason) and was surprised that takes so long. THEN I installed FastCopy. It was real operation and I was disappointed of that huge difference.

BTW. FastCopy refresh information just once or twice per second, not every file. I think is not huge work to limit displayed information in dialog per second.

PS. Now I think that give you zip with files has no sense. I don't want to publish my Firefox profile with my sensitive data (sites, passwords etc.) and if I generate exact number of random files - it will be like your "pathological" situation, not real one. IMO faster copy is worth investigate in my opinion. Lot of programs was created for faster copying files and there is a reason - people wants to do these operations as fast as possible and optimize problem is worth spent some time. I work very often with lot of small files and this is real problem for me.

No, I first want to have a safe copy, and then it should be as fast as possible.

I see no difference between "safe" copy and "unsafe" copy. This is not CD that if is burn too fast, it is burn worse. It's HDD that can read/write data as fast as controller (and programs) allows.

But - real test on real files:

github.com/joomla/joomla-cms/re ... ackage.zip

unpack by 7-zip - 2-3 seconds
unpack by DO - 7-8 seconds

copying files by DO (ram to ram) - 18-19 seconds (6-7 seconds when copy dialog is minimized)
copying files by FastCopy (ram to ram) - 1-2 seconds

Is this normal test enough?

PS. I understand that there are more and less important improvements/fixes. I can understand that image conversion is not that good as in Irfan View because "DO is not powerful image viewer", I can understand that FTP is not that good as Filezilla, because "DO is not big FTP client" (even if FZ is free and extra functions in DO are paid). But DO is filemanager, right? So it should manage files as good as possible - and that including not only "safety" (as Sasa says) but speed too.

You misunderstood what I meant with safe! No matter. I have no speed problems. So is the reason DO or your sys?

Do you test this link and made the same operations as me? Or just general "I have no speed problems"?

My values won't help you, because we don't use identical hardware (e.g. my CPU is faster than yours, DDR4 RAM,...). BTW I meant I don't have noticable speed differences between misc. file-managers. All is fast (or all is slow depending on the point of view :slight_smile:)

Are you talking about this FastCopy? If so, you can simply create your own copy buttons in Opus using the FastCopy command line and enjoy the best of both worlds.

Yes and sorry, it's not faster here with large and/or lots of small files.

It's also hard to compare copy-speeds (buffer, cache, etc.), of course it should not differ that much, but as said, I don't have these differences (also others not, you're not the only one comparing speeds and use DO for copying :slight_smile:).

But I don't know where your (large) differences come from.

I check this on fresh win7 on different computer with standard DO configuration. Still the same, so maybe win8 or win10 handles this refreshing better, I don't know. I'm using win7. Second time test - 12 seconds with copy dialog open, 6 seconds with hidden. Adding small option to decrease refreshing rate will be really useful. At least for some people. It will be nice if Opus, as powerful filemanager, can made these operations faster and better than other software. DO has thousand of options and I think one more really useful will be nice.

For now I'm waiting for few fixes that me and other people reported. It will be nice if this one can be on "to do" list too.

@Sasa: it's really great that you have no problems with copy speed, but this is not argument here; for every problem that someone report, other people can answer "I have no this problem on my computer". But that doesn't mean problem not exists.

You asked me to compare and test, I did, had no difference. So what you do want from me?! I can't say if it's DO or your sys, but you know it's DO, so I can't help you, because I can't reproduce this behaviour.