I recently introduced my first, fairly small C++ module (30-ish *.cpp files, 30k LOC total) to my UE4 project and have up until now only needed for it to depend on Core. When just depending on Core and building a non-unity build, the compile times have been pretty much what they were when the module was compiling completely without UE4, around 8-10 seconds.
However, as soon as I introduce "Engine" as a dependency in the module’s *.Build.cs file my compile times for that module skyrocket to about 2 minutes. Note that I don’t have to include a single Engine header in any file for this to occur.
Is this to be expected? The linking isn’t significantly longer, so what exactly is affecting the compile times, is UBT somehow injecting code/headers when building with certain dependencies?
Note that I’ve tried experimenting with various fields in UBT’s BuildConfiguration.xml, such as bUseUnityBuild, MinFilesUsingPrecompiledHeader, ProcessorCountMultiplier and bUseUBTMakefiles. bUseUnityBuild obviously has some effect, but it too is significantly slower when introducing Engine as a dependency.
After some painstaking debugging I’ve managed to track down the problem to one very likely cause, namely the length of commands when compiling each *.cpp file. When compiling with just Core dependencies, the command length is in my case around 2,500 characters. When compiling with Engine as a dependency the command length is instead close to 10,000 characters. Since this is pretty much the only difference affecting the actual compilation of the *.cpp files, I figured it must have something to with it.
Windows seem to have a couple of hard limits when it comes to the length of process paths and arguments. Visual Studio allows you to circumvent these by allowing you to specify a response file. At first I figured these limits were irrelevant since the compilation always succeeded just fine, whereas it probably shouldn’t if Windows somehow truncated the commands.
Despite this I gave it a try and implemented a quick hack in UnrealBuildTool where any Action involving cl.exe would move all its arguments to a temporary file and use its file path as a response file. This actually seems to more or less solve my issue, and brought back the compile times to a much more reasonable level.
We will probably end up using this as a temporary solution for now. But I’m still very eager to know if this is a known problem. I have a hard time imagining we’re the only ones experiencing this. And if it is, is there an official fix on the way?
A user on UDN hinted that it might be Kaspersky messing things up. Sure enough, that turned out to be the problem. As soon as I turned it off the compile times went back to normal, even without my dirty UnrealBuildTool hack. I sure feel like a fool now, but hopefully my diatribe will help someone out in the future.