Performnace drop in Dokany2.x when using mirror.exe

[adropit]

Feature request can skip this form. Bug report must complete it. Check List must be 100% match or it will be automatically closed without further discussion. Please remove this line.

Environment

• Windows version: Windows 10 - 1909
• Processor architecture: x64
• Dokany version: 2.0
• Library type (Dokany/FUSE): Dokany

Check List

• I checked my issue doesn't exist yet
• My issue is valid with mirror default sample and not specific to my user-mode driver implementation
• I can always reproduce the issue with the provided description below.
• I have updated Dokany to the latest version and have reboot my computer after.
• I tested one of the last snapshot from appveyor CI

Description

Hello,
We upgraded our program from Dokany1.4.1 to Dokany2.0.0.2000 (later added a test using Dokany 2.0.1.1000). Unfortunately, instead of a performance improvement, we noticed actually a performance drop…

In some tests using your mirror.exe example run with Dokany1.4.1 vs Dokany2.0.0.2000 vs Dokany2.0.1.1000 we noticed that the administrative rights play a big role in the performance. The tests implied reading over 9000 files sequentially using the mirror.exe provided by the Dokany release. The reading of files in our test program was done using three different C/C++ methods.
If both mirror.exe and our test program were run with administrator rights, the performance difference was slightly in favor of Dokany2.0.1.1000. But if both, mirror.exe and the test program (client), were run without administrative rights there was a massive performance drop when using Dokany 2.0.1.1000 if the files were read in chunks of 4KB. (See the attached document – section “DifferentRights”)

We also run a different set of tests using a Disk-Benchmark tool “ATTO”. This also shows some performance drop when using Dokany2.0.1.2000 compared to Dokany1.4.1. (See the attached document – section “Disk benchmark”). The Disk-Benchmark tool could only be run with elevated rights and we assume that without administrative rights the difference in performance drop would be bigger.
The last test was done reading (different) over 9000 files with the same three C/C++ methods where both the mirror.exe and the test program (client) were run without administrative rights. There was also a performance drop between Dokany1.4.1 and Dokany2.0.1.2000 in the case of sequentially reading in chunks of 4KB. (See the attached document – section “Own benchmark”).

So here are some questions from our side:
You provided some benchmark results for MemFS. Were the test run with elevated rights (both memfs.exe and your benchmark program)? (Can memfs.exe be run without elevated rights?)
Could you run the same benchmark using mirror.exe? (both with and without elevated rights)
Could you provide some benchmarks (Dokany 1.x vs Dokany 2.x) using the mirror.exe putting the accent on reading/writing files sequentially/random?
Performance_dokany.xlsx

[Liryna]

Hi @adropit ,

The benchmarks were run against memfs 5 times and in a clean environment without antivirus (even with the Windows defender disabled) to actually avoid having resources taken, requests being disrupted by other components and most stable results.
Mirror is totally contrary as it is under the mirrored disk activity constraint. If you add an antivirus, you will have biased results.

The Admin rights thing you are describing could be a sign of an antivirus or another app that interacts differently with the user filesystem.

You provided some benchmark results for MemFS. Were the test run with elevated rights (both memfs.exe and your benchmark program)? (Can memfs.exe be run without elevated rights?)

They were all run with admin rights but I do not expect to see a difference as memfs is not under external resource constraint and no antivirus was enabled.

Could you run the same benchmark using mirror.exe? (both with and without elevated rights)
Could you provide some benchmarks (Dokany 1.x vs Dokany 2.x) using the mirror.exe putting the accent on reading/writing files sequentially/random?

As said previously, mirror is really not what should be used for benchmarks. It is really just a sample and it was never focused on perf.

Read/Write improvements were not specially improved in v2 compared in other scenarios and the results I shared are reflecting it.
A real Read/Write improvement would be to implement caching. See #1047

Small remarks as I would not expect it to have any impact on your results: In your v1 benchmark you are using /t 8 which I imagine is due to the system having 8 cores. This is exactly what the v2 is fixing, using a system thread pool to use the right number of threads depending on the system it is run on. Most filesystems were just using the default 5 thread value.

[Liryna]

@adropit could you please redo your test with this change 231fc23 ? (it is not in the branch master yet)

[adropit]

@Liryna Unfortunately I cannot set my Windows in test mode. Therefore I can only test signed DLLs provided by your releases....

[Liryna]

I pushed multiple changes that improves the read/write scenarios. I still need to run the full benchmark but ATTO is giving good results especially on real world buffer size (4k -> 128k).
1.5.1:

vs head:

[Liryna]

See https://github.com/dokan-dev/dokany/releases/tag/v2.0.3.1000

[adropit]

Thank you for the release. I will also run some tests during the day.

[adropit]

@Liryna I ran my own tests today (no admin rights, windows defender on, read about 1000 files, 3.3GB) and I'm getting an average improvement when using Dokany2.0.3.1000 of about 5% compared to Dokany1.4.1.1000. This is an actually improvement considering that Dokany 2.0.2.1000 was slower compared to 1.4.1. I think that you are on the right track regarding the performance improvements in v2.

[Liryna]

Awesome thanks for the feedback. Are you able to see which buffer size was used during the read?

[adropit]

In my tests I try to read the entire file at once using C and C++ methods. There was a minor improvement there.
I also read the file in "chunks" of 8KB and 16KB. In this case I noticed the biggest improvement.

[Liryna]

I see. Thanks for your feedback and report!