My team is using arm-none-eabi-gcc.exe (Sourcery CodeBench Lite 2012.09-63) 4.7.2 to compile C++ from within Visual Studio 2013.
My colleagues recently upgraded their machines.
Old PCs:
New PCs:
The compile time for the exact same set of 96 files is:
Old: 60 secs
New: 104 secs
Compilation became slower despite faster CPU and faster memory.
I've observed this on several colleagues' computers.
At this point, you'd think it's a hardware issue except for the following: I had the new PC configuration since Sep-2017 and all of a sudden, without any hardware changes, I noticed that in Oct/Nov-2017 my compilation speed drastically slowed.
Therefore, I think it's a windows update that caused this issue.
QUESTION
How can I definitively deduce the cause for this slowdown?
CLARIFICATION #1
I don't mean that my compilation slows DURING a Windows Update. I mean that some windows update that occurred in the past causes my compilation to slow down.
UPDATE #1
I am using a blank .cpp file and compiling it 100 times and I'm still seeing the exact same time differences between Windows 7 PC and Windows 10.
I'm 99% sure it's a "bug" in gcc for windows. I installed gcc from the ARM website and I see the same issue.
However, when I use cl.exe to compile a blank file 100 times, it only takes 5 secs the same as gcc on Windows 7 and on older Windows 10 (Oct/Nov-ish)
My test script is:
set GCC_EXE="C:\Program Files (x86)\GNU Tools ARM Embedded\7 2017-q4-major\bin\arm-none-eabi-gcc.exe"
set startTime=%time%
echo off
%GCC_EXE% -c "empty.cpp" -o ".\empty.obj"
%GCC_EXE% -c "empty.cpp" -o ".\empty.obj"
%GCC_EXE% -c "empty.cpp" -o ".\empty.obj"
...
Windows Defender scans the GCC binaries repeatedly during the build.
Disabling "Real time protection" solves the problem.
Also, adding the folder, where the executable resides, to Exclusion list works.