I would guess that the simple task of updating the UI in Explorer eats a lot of cycles, so maybe a "turbo" output window that is updated less often and with less details could help. You might want to look at their comments here Bvckup 2 | Development notes | 19042018 if there is anything useful. I have also read through the notes of Bckup2 and it looks like their main speedup is by simply doing less per file and more per job in what they call prep/cleanup. (Yeah, you can do that with scripts and buttons too). As Robocopy ships with Win10/11, having an advanced config or commands for starting Robocopy would be nice. You might want to have Robocopy support as an optional copy command for multi-threaded copying (which CopyFile Ex won't do). Good reasoning, Leo, it has to work reliably for everyone! But sometimes it is worth it, too, once evaluated and tested for a long time. Experience has shown that a change which seems like a good idea in this area, and might speed up one scenario on one machine, can end up causing more trouble than it is worth. It's core functionality, mistakes with it can lead to data loss, and it has to work well on all systems. It's possible we'll look into this in the future, but it's not going to come soon, as we're very conservative when it comes to changing and testing the file copying code. (Although this isn't out of the question, and may eventually come for things like FTP where parallel copies are unfortunately still the only way to solve those protocols' inherent problems with network latency.) We also need to have a reliable and understandable interactive error/retry UI, which would be complicated by doing multiple files at once as part of the same copy job. It's also very hard to properly test copy speed, due to all the buffering the filesystem does and the huge impact different hardware/software/network configurations can have on what should be minor differences in method and buffer sizes, as well as the types of metadata being preserved, etc. Microsoft Antimalware real-time service was disabled during test's, as I find it to interfere with file operations a lot.įile copy has to be rock solid on everyone's systems, and for every scenario (copying 100,000 almost empty files isn't that common, for example, and isn't the thing to optimise for, especially when none of the copy methods actually take very long). disabled.Īll tests performed on relatively large folder structure of C++ libraries which can be easily reproduced.ġ) Download boost 1.80.0 libraries for Windows from (eg.7z archive) and extract.Ģ) Build Boost 1_80_0 to also build non-header-only libraries - I did this with VS2022 Community. ![]() ![]() Also, it's interesting to note that Bvckup achieves this high speed despite also copying Alternate Data Stream's and logging copious amounts of data on the copy operation.ĭOpus had copying of attributes, metadata, timestamps etc. I haven't found a faster copying engine yet (including FastCopy and TeraCopy). ![]() This thread is about Copy optimisation, where a multi-threaded highly optimised copy engine (as shown with Bvckup2 R81.24.1) is shown to be faster, particularly for SSD's, which only show their true portential with multiple I/O requests in motion at a time - ie. ![]() Further to the following thread, requesting various optimisation's that would be nice in DOpus 13, I have spun out into separate threads the various optimisation's and benchmark results.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |