It occurred to me that the way the UE4 VS solution is structured is a bit bizarre. The entire engine, with all of its plugins and modules, is packed into a single project that outputs dozens of dlls. Likewise the game itself is packed into another project, along with all project-specific plugins and modules. Only the supporting programs (shader compiler, UBT, UAT, etc) get to be placed in their own projects. This has a few drawbacks.
First, you cannot easily limit the scope of a “find in files” search to a specific module/plugin. Setting the search scope to “current project” in the UE4 project will search across all modules and all plugins. On the game project any project-specific plugins are also included in the search.
Second, you cannot easily rebuild a single module dll.
Third, I suspect this structure may play a part in Intellisense’s abysmal performance on the UE4 codebase. I recently had to dabble with the CryEngine source and was surprised by how much faster Intellisense was on it. It was even possible to use “find all references”, which takes so long to produce results in UE4 that I’d rather do regex searches across the whole solution/project. The ~20% difference in codebase size doesn’t seem to explain such massive performance difference, which led me to suspect the fact CE’s more traditional one-project-per-dll structure might have something to do with this.
UE4’s monolithic project creates a massive list of external dependencies and from Visual Studio’s perspective the separation between modules doesn’t exist: a function declared in a .h file could have its implementation in any one of the thousands of .cpp files that make up the entire engine, even if compilation-wise it could only possibly exist in the files that belong to that header’s module. I’m not too knowledgeable in the inner workings of Intellisense, but I suspect having a an include search path list with over 2300 entries doesn’t make it’s job any easier.
I’ll see if I can set aside some time to toy with the UBT VC project generation code and see if there’s any gains using a structure where each module has its own project, but it would be nice if I could get someone at Epic to think about this.