I haven’t used Inform7 much at all, but I have tried it and noticed the surprisingly long build times. I’m a software engineer who’s seen these kinds of bad interactions between compilers and anti-malware software a lot. I know that sometimes a relatively simple change in how a program produces files can eliminate the bottleneck. I’d love to help everyone facing these slowdowns.
I downloaded Inform7 to my Windows 10 machine, and confirmed that, with a trivial story, the compile time is less than a second but about 10 seconds according to the clock on the wall. I also confirmed that turning off the “real time” Windows antimalware software completely eliminated the delay.
Next I used Sysinternals Process Monitor to watch what ni.exe (the Inform compiler) and MsMpEng.exe (the MS malware scanner) are up to. It’s strictly a file I/O bottleneck: neither application is hitting the network nor is either spending excessive time on registry lookups.
Other than ni.exe loading up a disconcertingly antique version of the CRT, it seemed well behaved. But even in ProcMon, it was easy to see that the output of each HTML index file was momentarily blocked as MsMpEng scanned the previously emitted one. But it wasn’t quite clear why it was blocked.
So I took an event trace (using Bruce Dawson’s UI4ETW) and tried to learn more in Windows Performance Analyzer. (I needed more practice with WPA anyway.)
My first observation is that the Windows search indexer is doing far more scanning of the files ni.exe is creating than MsMpEng, and yet it doesn’t seem to have any direct impact on the speed of ni.exe (assuming you’ve got a spare core for it to run on).
Eventually I found that, somehow, ni.exe gets blocked trying to create each file while MsMpEng scans the previous one. None of the delays are particularly large, but there are just over 100 of them, and they add up to about 9 seconds, which is consistent with the observations.
But it didn’t make sense to me how one process scanning the previously created file could block creation of the next file. It seems like those should be able to run in parallel.
So I loaded up the symbol files (PDBs) and tried to look at the stacks. Fortunately, Inform7 provides the PDBs. Unfortunately, they are in a very very old format that WPA doesn’t support, so ni.exe stacks are completely opaque, which prevented me from making much more progress. (The old PDB format is consistent with the very old version of the C run-time library.)
I found a 2019 article that said Inform was going to be open sourced, so I hoped to see if I could recompile ni.exe to get a modern symbol file. Alas, the open sourcing of Inform isn’t yet complete.
My best guess is that the very old CRT library may be blocking file i/o on some global(ish) lock because the library wasn’t very thread savvy back then. I know other security software installs filesystem drivers that can slow down file i/o for all processes, but MsMpEng seems to be a plain old user-mode scanner that uses standard i/o calls, so I’m not sure why it would have this kind of impact when the search indexer doesn’t.
Once Inform7’s repo is made public, I think we’ll be able to figure out the root cause. Hopefully, we can update how the Windows version is built so that it’ll be more amenable to analysis tools.
In the mean time, it should be enough to grant some exclusions in the Virus & Thread Protection Settings.