I recently migrated from Windows 10 to Windows 11 and also upgraded DOpus to newest version. I've noticed the following behavior that I do not remember ever happening on my previous setup/DOpus version.
Steps to perform in DOpus:
Prepare a zip containing some large file (let's say more than 2GB).
Move this zip into a SMB (new SMB, not legacy SMB1) share with r/w access.
Open this zip on the SMB share, you'll see the file(s) normally.
Copy the compressed file (from inside of the archive) into your local SSD drive. <- file copy speed is at least one order of magnitude slower than it should be. Network saturation, HDD use and CPU usage is marginal.
Cancel the operation and copy the whole zip to local drive and unpack it there. <- no problem here, you can perform those actions at least 20 times before unpacking a single file directly from zip finishes.
It's repeatable with different files etc. Connection is wired ETH LAN.
I've tried Windows explorer with the same zip on the same share and same system. It was still far from filling up available bandwidth although it was around 7 times faster than Opus.
You could try turning off the internal zip support in Opus, and switch on Zip via the Archives plugin (which uses 7z.dll). That may be faster for the scenario you're testing.
Those changes are done here:
Preferences / Zip & Other Archives / Zip Files
Preferences / Zip & Other Archives / Archive and VFS Plugins
Indeed, this made the operation I described very fast!
The opposite operation (compress to zip, even without any SMB use, just local SSD drive) is now 13,5 times slower, though. Also the switch "use multiple cores" seems to be ignored when it comes to regular zip (not 7z).
I believe there is no option to use one for decompression and the other for compression?
Once I disable Opus built-in zip suuport the context menu on file "Add to something.zip" is gone so I use regular Opus "Add to archive". Then in dialog I pick zip, deflate, best compression and no password (as I don't want encryption).
I measure time with a regular stopwatch although the difference is immediately visible by just looking at it.
Turn it on under Preferences / Zip & Other Archives / Context Menu. (If there are two entries for Zip there, the plugin is the "Zip" one while the internal one is "ZIP" in uppercase.)
I think that will run faster. At the moment, I have a feeling the Add To Archives dialog will close and re-open the archive for each file it adds when adding via plugins, at least in some situations. (That is on our list to improve.)
Unfortunately speed does not change no matter what option to create archive I pick. It is visible even on single file.
What is more I found a small annoyance. If I disable built-in Opus zip support and save the settings I loose the list of extensions of ZIP files that were configured on that page. It kind of gets back to some default once I re-enable this built-in support and I have to add my custom extensions again. Could they stay grayed out as it is in the zip VFS plugin setup (it stays there even if I disable the extension for plugin)?