Optimise Delete

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.

This thread is about Delete optimisation, where multi-threaded delete is shown to be MUCH faster, particularly for internal SSD's, although they all show a doubling of speed.

All tests performed on relatively large folder structure of Boost.org C++ libraries which can be easily reproduced.
1) Download boost 1.80.0 libraries for Windows from boost.org (eg. .7z archive) and extract.
2) Build Boost 1_80_0 to also build non-header-only libraries - I did this with VS2022 Community.

Microsoft Antimalware real-time service was disabled during test's, as I find it to interfere with file operations a lot.

All timings in seconds.
Number of runs vary between tests

Test
Delete from type...
DOpus 12.28.2 beta Time to Complete ByeNow v0.5 Time to Complete Explorer rmdir
Internal PCIe3.0 M.2 SSD
WD 256GB
40, 40, 39 4.44, 4.80, 3.92, 5.10, 3.22, 4.30 15, 16, 17, 16
External USB3 2.5" HDD
WD 5TB
37, 36 21, 20, 18 58 37, 37
External USB3 Flash Pen Drive
Samsung Bar Plus v2 64GB
35, 35 17, 16
External USB3 SATA3 SSD
Samsung 850 Pro 1TB
24, 24, 23 9, 9, 9

Most deletes go through the recycle bin, where this wouldn't affect anything as the operating system handles everything itself (we just give it a list of files to recycle).

And some devices, drivers, antivirus, or cloud storage tools go much slower or even lock up completely if unusual things are done in parallel. The time difference would have to be extreme for it to be worth the risk of compatibility issues.

You mention disabling antivirus. That's not a realistic test for most users.

I forgot to mention, the tests were done when by-passing the Recycle bin (which is how I normally do deletes), and the Microsoft AV specifically was disabled because it slows down the system from my experience, related to file operations - not just for file copy. It may have high detection rates, but if using an AV, I would suggest using an alternative. which has less of an impact on the system.

ByeNow is not doing anthing particularly unusual - it's just optimised, and a ten-fold increase in delete speed on SSD's (which is pretty much the standard and future for internal storage) is pretty extreme IMO.

I'd be interested in other people posting result's from their system's, for comparison, given Boost and ByeNow are available to anyone.

I usually want all my deletes through the Recycle Bin unless it is one single large file (where I shift-Delete it) and even then I have managed to delete the wrong file once in a while. And I will not turn off Anti-Malware. This sounds a bit like "I know the acceleration a hacked Tesla can do, so please enable that on your car model too, what could possibly go wrong?"

And finally - the Delete is running in the background anyway, I am usually not watching the delete and do other things instead.

1 Like

The AM being disabled caused more issues for the Copy tests, and was disabled to speed up the benchmarking.

MS AM does seem to be less optimised than other's, and doesn't have the ability to whitelist files based on their signature. But it's free.

Just re-did delete test with MS AM enabled and the results were:

DOpus   86
ByeNow   5.35

So it actually affects DOpus more than ByeNow.

This sounds a bit like "I know the acceleration a hacked Tesla can do, so please enable that on your car model too, what could possibly go wrong?"

Using MS AM is more akin to driving an un-hacked Tesla with the handbrake on. :slight_smile:

I'm not saying don't use an AV/AM, but just use a better one.

Checking sources like
Test antivirus software for Windows 10 - June 2022 | AV-TEST
I see no indication that there are any significant speed differences in file copying with ANY AV/AM - they all have roughly the same performance hit of 5% for a bunch of files. Including MS Defender.

I’ll depend what’s being copied and how. Writing an exe file will make most virus checkers scan it. Opening one for reading may as well, if they haven’t already scanned it and cached the result.

Huge fan of Byenow. I especially love it on network shares. It really is faster.

My button:

<?xml version="1.0"?>
<button backcol="none" display="both" label_pos="right" textcol="none">
	<label>byenow</label>
	<tip>byenow</tip>
	<icon1>D:\Tools\byenow-0.6\byenow.exe,0</icon1>
	<function type="normal">
		<instruction>cd &quot;D:\Tools\byenow-0.6&quot;</instruction>
		<instruction>@async:&quot;D:\Tools\byenow-0.6\byenow.exe&quot; -t 20 -y -1 {filepath|noterm}</instruction>
	</function>
</button>

I caution everyone not to use it until very complete testing. It will make things disappear.

Yeah, my comment was more in the direction of "The speed impact on copy (and I am on the wrong thread here, this is the delete thread) is nearly identical on all solutions tested."

1 Like