False positive from Windows Defender?

[gvanem]

Running a 2 month old rg.exe just now triggered this warning from Microsoft's Windows Defender (MsMpEng.exe?) process:

The Virus reference does not mention any details. But Reddit mentioned it 3 years ago as something MS is looking into! Nothing on Symantec.

And immediately placing it in quarantine. But getting the tip of git master just now, building and running that, all is well.
AFAICS, the diffs from these 2 versions where not so significant. But could it be some other Rust package that's to blame?
Has other people see such false (or heaven forbid true) positives on rg.exe?

[BurntSushi]

Ummm, yes, obviously it's a false positive.

I've seen this happen from time to time with various "helpful" tools on Windows.

I do not use Windows and do not claim to understand how these tools work and what their detection mechanisms are.

I do not know what your path forward here is unfortunately. I'd say "ignore it," but that's probably because the first thing I do when setting up a Windows machine is disable all that crap.

[gvanem]

Thanks. I'll just white-list it and hope Windows Defender shuts-up about it.

I love this tool for it's speed. I mostly use it to search through various SDK headers;
It was fast on my old Intel-I7 PC. But on my new AMD Ryzen 9 PC, it searches through 360 Mbyte of .h-files in 1 sec!

[BurntSushi]

But on my new AMD Ryzen 9 PC, it searches through 360 Mbyte of .h-files in 1 sec!

Wow. That is actually... quite slow. I can search a 13GB file in about 1.5 seconds (when that file is in memory):

$ time rg ZQZQZQZQZQ OpenSubtitles2018.raw.en

real    1.508

And I can also search the entire chromium repository (which is 4.5GB) in less than a second:

$ time rg -uuu ZQZQZQZQZQ

real    0.614

Are Windows file operations really that much slower? For reference, my CPU is a beefy by dated Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz.

[gvanem]

And the wall-clock time? AFAICS, the real > (user + sys)/(num cpus).

So I ass-u-me the slowness on Windows is due to several factor:

• file-cache on Windows is way simpler than on your (?) Linux box.
• rg.exe is not using all my 24 cores. How to tell?
• the timer program (a built-in in my 4NT shell) is too coarse perhaps.

[BurntSushi]

real is wall clock time. It's the time that elapses between when I run the command and when the command exits.

You could try running rg with -j24.

Otherwise, I don't really know. I have been vaguely aware that file ops on Windows are generally slower than Linux, but your times are kind of ridiculously slow.

[gvanem]

Yes, but rg.exe uses only 0.01% CPU with the -j24 option. With time.exe (a Msys 2018 version) and Qt6's examples in cache:

f:\gv\Qt\Examples\Qt-6.2.4> time.exe --verbose rg.exe -j24 --mmap --fixed-strings main( .
 ...
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.28
...

881 hits.