I asked for test and I expected some informations - operating system, computer configuration and results (FastCopy vs DO in seconds). I don't know if you have win7 like me or win8.1. Graphics interface and speed may be depend on os too if problem is, what I suspect, in gui.
"I have a fast SSD"... what is a fast SSD? I have a M.2 NVME, so fastest SATA3-SSD is relatively slow (on the paper). Also all other hardware and OS (Win10) differs from yours. So the only thing we can compare is if there's a markable difference between FC and DO. And I have none.
As long you're the only one reporting such large differences (small differences are normal), it's hard to find out what's going wrong. If you think it's a gui issue, did you try another gfx driver? BTW the copy-graph will be optional in a future release, maybe deactivating then will fix your problem.
Sorry, I also have no idea and I'm no dev, but maybe GP will find out what's wrong. Good luck.
I mean windows gui - what system handles displaying windows, fonts etc. Win8/10 seems to be faster in that type operations. "Fast SSD" is not an issue because I tested this on ramdisk drive, which is much faster than yours M.2 ssd and any other ssd. I am not the only person who report this type of problems - I search this forum and found that the same problem was reported in the past (previous version of DO). I don't think it's related to copy graph. I think it's related with displaying filenames.
I ran a few tests:
Windows 10 Home Edition with the recent Anniversary Update or whatever they're calling it
Lenovo T530 laptop with a Samsung 850 EVO SSD drive installed by me...
Opus v11.19
FastCopy v3.2.1 (64-bit)
Vivaldi browser only other desktop app open (on this forum page)
Windows Defender for AV
Sample dataset from my Vivaldi profile, copied over itself several times to increase the size and file count
[ul][li]485 MB[/li]
[li]1,248 files spread across 62 directories[/li][/ul]
All mostly native Microsoft drivers from my own clean install of Win10 (not an upgrade) using the ISO-to-USB bootable install media from the MDT for Win10 - except for some chipset, LAN and Audio drivers from Lenovo. NOTABLY, I left the default Intel VIDEO drivers provided by Microsoft in place... because my graphics options and controls were 'good enough' (better dual monitor support than the Intel drivers on the same laptop under Win7 actually) and the video driver downloads from Lenovo's website were actually dated OLDER?
Test 1:
FastCopy (command line via Opus hotkey):
/jtools\fastcopy\fastcopy.exe "d:\my\temp\source\*" /to="d:\my\temp\fast\"Opus (raw command via Opus hotkey):
copy "d:\my\temp\source\*" to="d:\my\temp\opus\"Results:
FastCopy: Consistently either 6.0 or 6.3 seconds (as reported by the FastCopy dialog after bringing it up from the system tray, copy otherwise runs with the dialog suppressed via the command line)
Opus: Consistently around the same 6-ish seconds (a bit inexact as I'm clicking a stopwatch timer right after hitting my hotkey, and then again as I watch the minimized progress indicator complete, but the timer never reached 7 seconds)
Test 2:
FastCopy:
This time via the UI, which has an EXECUTE button to re-run the previous operation. So this time doing the same thing as the command line but with the dialog visible in the foreground.
Opus
Via hotkey still, running the same command - but with the 'Minimize progress indicators' option DISABLED in Prefs to force the progress dialog visible and in the foreground.
Results:
FastCopy: Consistently either 8.3 or 8.8 seconds (as reported by the FastCopy dialog which stayed open during the operation).
Opus: A bit less consistent, ranging between 8-ish and almost 10 seconds (again, still a bit inexact as I'm clicking a stopwatch timer right after hitting my hotkey, and then again as I watch the progress dialog disappear)
And... these were my results even without disabling my normal copy options for preserving attrs, ownership, etc in Opus.
My own personal conclusion?
Yeah, it seems that the Opus progress indicator brings a bit more overhead into things - regardless of it being on a separate thread. These results held true across a dozen repeats of each utility. However, there clearly seemed to be overhead with the dialog vs withOUT the dialog for BOTH utilities. I'd chalk that up to driver induced or other systemic ~stuff in general though, AND let's be real - the Opus progress indicator is doing a bit more than the FastCopy UI's basic textual progress window (Opus has bar graphs, individual filepath updates, etc)
I realize that the original poster still seemed to encounter some elongated copy times with Opus compared to FastCopy - even with the progress dialogs minimized, but if the argument is to build progress indicator refresh rate controls into Opus - then in my mind the counter-argument seems pretty simple: If you're concerned about Opus's copy speed... stop watching the dialog 
. It's like watching grass grow or water boil. Just don't do it...
I can even tell you that I otherwise DO have some copy issues with Opus in other situations, mainly to do with large file transfers to external USB drives where Opus seems to just stall after reaching 100% on some files before moving on to the next one, which I imagine is a drive caching related thing - but which I've never been able to duplicate with Win Explorer (at least not to the extent I often see in Opus). But I've judged hunting this sort of issue down to be just too irritating and time consuming to try fixing by playing around with things like the buffer controls that GPSoft added to the product years ago - specifically to give people with ~other types of copy performance issues than yours some ways of turning knobs in order to tune. Which - by the way - was done in response to observations like your own over the years.
But that's my choice of course... to the OP (peterb), all I can say is that this is exactly the sort of rathole that Leo described as consuming lots of time over the years, never seemingly ending anywhere conclusive. Hopefully you don't feel your argument is being dismissed out of hand without any regard, I think Leo posting rationale experienced-based responses proves otherwise - even if you don't like the end-result. But I will say I have watched these topics play out on the forums for YEARS, and there just doesn't seem to be a right answer for everybody. And I think the 'assumption' of that being due to system differences is a little more than just an unfounded or knee-jerk guess... Somebody here will post test results that are closer to yours than to mine, which for the record - in summary of my own tests - show close to ZERO difference between FastCopy and Opus when both utilities have their progress dialogs minimized/not visible (unlike your results which still shows a difference). And as a user who asks for stuff ALL THE TIME, I'd much rather see the devs spend their time on other things than something like copy progress refresh rate controls - leave it minimized and move on. But I get that if you're passionate about it... you'll want to forge on with your requests for optional progress controls, it's certainly your right to ask and plead your case of course.
Final comments: So, just as you gave Opus a bit of a pass on not necessarily being 'as good' an FTP client as FileZilla, or an image manipulation program as IrfanView, keep in mind that you're also comparing an all-around File Management application to a tool that is ONLY a file COPY/DELETE tool, which is actually called FASTCopy, and which purports to be the "The Fastest Copy/Delete Software on Windows"...
I'm all for improvement of Opus - but just sayin...
1 Like
Thank you for your complex test and answer. I still think that it may be related to win7 gfx handling. If at least one person with win7 can do this test - it will be great.
I'm just curious - few programs I've tested for copying files have the same method to do it fast - do not update info every 1/60 second or every small file. If it works in other programs, maybe is worth to at least try to do it in DO. Is not like made completely different and very complex code.
I use Opus10 in my workplace (upgraded from Opus9) and, if I remember good, update rate was changed once before for progress dialog. Maybe now is time for made something similar here but for text informations?
As you said, there is no big difference in your case but still, your system is different.
Opus won't close the progress dialog until the data is flushed to the disk/device*. I'm not sure but Explorer may close it once the data is in the filesystem's write cache. (*At least for some device types. I'd bave to look at the code to tell if it was all or exactly which types, as it's been a while.)
If you're using non-buffered I/O then things can look quite different as well, even though the real time to get the data from A to B is probably the same.
Explorer also uses "progress bar smoothing" which is off by defaut in Opus, but can give the impression of the progress bar still moving towards 100% when the program has already set it to 100% and is waiting for the final file flush and/or close.
Progress dialogs are actually a pretty bad way to compare copy speed between programs. So much can differ in how they report metrics and when they close vs when the operation is really finished. It's often better to look at a graph of disk activity, although I don't know how well that works with lots of small files.
Yes, if I copy from WLan to WLan, the progress dialog remains at 100% in DO until cache/buffer has been written to disk. BTW the time at 100% depends on filesize (the larger the longer), so you can't say it will stay always x seconds (because buffer has a fixed size), which means that it is nearly impossible to compare like you (Leo) said.
Thanks Leo - I get it. Don't want to pollute the thread more than I have with a separate copy ~thing.
BTW. I was trying to change font in progress window, but I cannot find any settings for that. Is this possible?
@peterb: .. Which columns have you specified in source and destination?
I'd the same slow problem with sync because by default I had name, ext, size bytes, size auto, attr, modified, created, location, owner.
I think after each copy of a file the owner and location have been detected and updated in the source and destination - which costs time.
I also had as column the duration of my music files or e.g. another ID3 tag - and it looks like DO has started to read the information of these files during copying the next one ... don't ask how much longer the sync has needed. 
When I switch into SYNC I've made another folder format for Synchronize and only have the columns name, ext, size bytes, attr, modified, created on source and destination and the copy action is very fast now. Maybe the columns could be reduced and DO might be faster again - but never tried it.
I hope this info helps.
Ok,
in DO 12 - I updated all my settings and now when I start the synchronize, the columns "Location" and "Owner" (which are included in my default format) don't go "away" when I use the SYNC format. Why?
Lock is not set.
Please start a separate thread if you need help with folder formats. This thread is complicated and multi-faceted enough without going into parallel topics
Please check what the format lock infotip says when you hover over it and include that info in the new thread if the infotip itself doesn't answer where the columns are coming from.
Yes, it's different problem (in your case it's natural - more informations needs more time to read). I was talking only about copy speed (I selected single directory without read any info from inside).
This thread caught my curiosity so I checked out Fastcopy and tried some file copying. Nothing sophisticated...but I used ~50GB of video files (not tiny files) with Win10 & DO v12. FC was slightly faster (~6 sec) but it's a tiny percentage differential, maybe 1-2%. What I don't get is the comparison of FC to DO. They are different animals. You can't compare FC which only copies files. Write some batch files and stick it in Task Scheduler and it's automated. But the user interaction with DO, come on....there is NOOOOOOOOO comparison. That's like focusing on the width of the tread on a tire and ignoring the fact that there is a car connected to the tire.
In principle, I've always liked to avoid massive video I/O (the graph, filenames, etc) because it is relatively slow but not sure how much it means given today's hardware, etc. Would I prefer a routine that doesn't display each filename? Based on my programming strategy...Yes. Use a timer with a 100-300ms interval and only update the display with filename, etc when it fires. But again it only matters with tons of tiny files...maybe.
BTW, in Preferences > File Operations > Progress Indicators, I've unchecked the top 2 items (Count files in folders....).
Bottom line...FC is NOT a file manager. DO is an amazing file manager plus more!! Is DO worth buying...100% no-brainer. I've been using DO for nearly 2 years and still amazed and discovering new goodies. Wish I had it 30 years ago...if only.
Enjoy all!
Even with the speeds so similar, chances are it is not an apples-to-apples comparison. You'd need to ensure both programs are copying the same metadata and measuring the same operation (e.g. reads/writes from/to disk vs from/to cache).
A 2% difference is well within margin of error, even without those differences which can account for a huge time difference if not the same in both, so I'd say both programs are probably the same speed on your hardware. Which shouldn't be surprising; they both ask the OS to copy data and the rest generally happens as fast as it physically can happen.
Oh, excuse me, but your test has no sense here, in this topic. I was talking about how displaying informations affect on copying lot of small files and you compared huge video files. I was talking about possibility of slow down on win7 and you testing this on win10. In my case big files are copied the same or similar speed in FC and DO, so your results not a big surprise for me. I was not talking about speed of writing files, I was talking about slow down operation because of other factors - too many useless informations (like filename that displays for 0.01 second and copy window refreshing every frame or even often).
I also think that DO is great, but hey - it doesn't mean that I must be some kind of worshiper - if something works bad, I want to report that and I expect someone look at problem. I prefer programmers who at least trying to check problem instead of saying that "everything is ok", because it means that in the future other bugs will be fixed, not ignored or considered trivial.
File manager is program for file operations. Copying files is one of most important file operations, isn't?
And about "the same metadata" - I though that I already prove it's not like that when I turned off all options in "Copy Attributes" section?
PS. One more about test made by steje. His test contains "485 MB, 1,248 files spread across 62 directories". My test was on "680 MB, 14,541 files (!) in 2162 directories (!!!)". So - over 11 times more files and 34 times more directories with only 40% greater size. As I see, problem is bigger when I must copy lot of small files. So if in Steje's test was only 2 second difference (dialog open or hidden) then in my case it will be 11 times more. And still there is different OS, which as I suspect is important factor. Really - all that informations in copy dialog should not be refreshed every file, especially if changes are under 1/30 second.
I can assure you, just have a look in the changelogs.
But today I extracted actual wordpress installation with shown and hidden dialog (from disk to disk). When hidden it was really 15-20% faster (I always use hidden, so I didn't notice a difference).
I can confirm that copying the files in the sample zip file on the previous page is faster with the progress dialog minimised. Not sure why yet. We will look into it.
My guessing is font display on dialog box. But it's only guessing (although based on my small experience as programmer).