We just got McAfee installed, and the performance is horrendous on `npm install`. Even something like kicking off headless Chrome to run unit tests now takes 5 mins instead of 30s.

So yes, this is probably a major concern for a product that actually cares about their user's performance.

Get it changed from "scan all files", which humorously scans things like .css and .jpg files for malware, to "scan executable files". This has a huge impact on McAfee's performance, and has for years.

Sadly it's controlled by the higher ups who worry about 'security'... never mind that it decreases programmer productivity quite a bit!

Wasted developer time = wasted money.

How much wasted money could they save each year by changing this setting? You need to speak their language. If you can legitimately show that it costs 15k per year to have that checkbox on, they will act.

Performance is important when you are scanning all system IO for the "I Love You" virus.

The only sandbox I apply to this "realtime scanning" is to disable it wholesale. Instead of this waste of a Moore cycle Microsoft should add a few more patch days.

I'm sure all the people who already pitch a fit about updates and restarts would be thrilled.

"Performance reasons" meanwhile I kid you not when I say that the Antimalware Executable of Microsoft swallows about half my CPU performance when I am downloading, unzipping, executing files. They could have implemented their antivirus in JavaScript and it wouldn't have mattered.

implemented in JavaScript... something like this?

https://bugs.chromium.org/p/project-zero/issues/detail?id=12...

> The core component of MsMpEng responsible for scanning and analysis is called mpengine. Mpengine is a vast and complex attack surface, comprising of handlers for dozens of esoteric archive formats, executable packers and cryptors, full system emulators and interpreters for various architectures and languages, and so on. All of this code is accessible to remote attackers.

> NScript is the component of mpengine that evaluates any filesystem or network activity that looks like JavaScript. To be clear, this is an unsandboxed and highly privileged JavaScript interpreter that is used to evaluate untrusted code, by default on all modern Windows systems. This is as surprising as it sounds.

Time we bring back the C64 design, with no internal storage?

And no networking.

Try TempleOS, though a scamp from /g/ implemented a full network stack, along with video players, etc.

And thus the first shim was formed...

I had to create exclusions[1] for some stuff (mainly visual studio) because I had the same problem (mainly during builds).

[1] https://www.drivereasy.com/knowledge/antimalware-service-exe...

I don't fully understand this - It isn't critical to virus scan files when reading or writing them. It's important to scan them between a write and a read.

That means many written files (which won't be read for a long time) can be scanned hours later.

Others can be checked for matching a "known good" hash whitelist which can be downloaded from the net. That should cover all kinds of files which are parts of software distributions etc.

That leaves very few files which really need real time scanning.

Problem is, for example, if you compute checksums of many files after writing them...

At the same time, it's miles better than AVG!