I am interested to know why UE Depends on Visual Studio the very bolted compiler even made for C# and not for C++ , the support for C++ was added later.
This compiler will use 50% of your CPU and will decrease the time of compilation, basically wasted 80% of your time and will force you to buy incredibuild which is a third party source and nobody want to trust this kind of third party source to grant permissions to accelerate your build time… this means they will have access to your code while incredibuild is not working without an internet connection.
I would recommend epic should release a paid dedicated C++ Compiler for C++ UE4 projects.
Are you absolutely sure about that? I’m pretty sure there was Visual Studio C++ support before C# support. I used Visual Studio in high school ('96-'00) and C# wasn’t released until '01.
While there are perfectly valid complaints against C++ in general and its compilation model, the problems stem from the language and not really from anything intrinsic to the compiler. I think it is unlikely that Epic would be able to build a compiler that much better than the one that Visual Studio uses.
There’s a lot that you can do to reduce compilation issues when building that don’t require Incredibuild or one of the other distribution tools. Good code organization and smart header inclusion go a really long way to having reasonable compile times. Yes, you can hit that one header that makes you rebuild a lot but you can minimize that sort of impact. I’ve never felt forced to buy Incredibuild for any home project, including UE4/5. Not that it would do me any good only having a single machine to build with.
Visual Studio has its problems as well and it might make sense for them to make a custom front end, but if you’re unhappy with the IDE, there are already alternatives that you can work with. VS Code is supported and I’ve heard good things about the Rider Beta from JetBrains from a colleague.
But it would frankly be a real waste of their time to spend it on a C++ compiler. They wouldn’t be able to actually fix any of the issues actually causing long build times.
Actually, quite the opposite. Years ago, I sent an encouraging email to people at Microsoft to expand support for different languages and different platforms because Visual Studio worked well, and the company mantra was to open computers to the world.
That seems more like a replacement for a CI/CD tool like Team City. It doesn’t really seem like a solution to local build issues like they are complaining about. But I’m not all that familiar with it, just based on what I’m seeing from the front page.
As for build times I did encounter a [GenerateProjectFiles -CurrentPlatform] option. I do not know if this works for certain though. I have used but ran into an issue with the Python plugin. After enabling the scripting plugin and upon restarting the project it failed (I believe). I updated the Visual Studio solution, rebuilt it, and was able to continue working.
However, I am now using a full version because I am not sure of the impact of the -CurrentPlatform option. I may go through the details of the option later but for now I am staying with the full build.
I am disappointed of how long Setup.bat took though. That was painfully slow. . .
Setup.bat and compiling shaders should be done at the system level and not needed at the project level unless the target is different (of changes occurred on Gihub for Setup.bat).
And you can change an option to let the shader compilers run wild at the expense of getting a hogging resources during packaging times.
Engine\Config\BaseEngine.ini
[DevOptions.Shaders]
; Set process priority for ShaderCompileWorker (0 is normal)
WorkerProcessPriority=-1
And this value is read in Engine\Source\Runtime\Engine\Private\ShaderCompiler\ShaderCompiler.cpp:
// Launch the worker process
int32 PriorityModifier = -1; // below normal
GConfig->GetInt(TEXT("DevOptions.Shaders"), TEXT("WorkerProcessPriority"), PriorityModifier, GEngineIni);
I can explain how this idea comes in my mind, actually I have managed to use CodeBlocks with UE4 and found 70% to 80% performance increased and the CPU lows down from 52c to 30c, but the only problem with this compiler you have to load all the files manually and compile to sea the result in the editor, it will not restart the editor on every compilation, you have to do it manually. CodeBlocks IDE uses a powerful C++ compiler GCC and absolutely open source.
I think this will not be a problem if EPIC will take this IDE as a reference or template and build this further and optimize for UE4/5 …
@c0r37py Well IDE’s and compilers are pretty inter-changable. For non-UE projects you can definitely build with the GCC compiler within Visual Studio. Since all the project settings are auto-generated there may already be a switch somewhere that would allow you to switch the settings to a different compiler similar to how you can switch the project version for the different versions of Visual Studio. Or maybe that’s a user setting that won’t get overridden when regenerating the project file (like the command line options in the settings).
Loading files sounds like a CodeBlocks problem and not the compiler, but I haven’t used that IDE before. I do know that at work most of our automated builds use GCC from a command-line just fine, so the compiler can load/compile whatever files it’s told. If the IDE won’t tell it to compile files that it doesn’t have loaded, it’s not the compilers fault.
Visual Studio is not the compiler, cl.exe is and there are the build tools.
If you install these you can compile without visual studio, you just need microsoft C++ built tools.
I don’t have visual studio installed.
They gave these built tools an acward name, like visual C++ build tools, but they are not, these are the old build tools that come with the microsoft compiler included, they are just the Microsoft C++ build and compile tools without any visual studio that I do not like at all.
My few cents, though I’m not really using UE on daily basis.
1st,
If you like GCC, you can actually hook it into Visual Studio. I used to do that while doing games for other platforms years ago.
Fun Fact: I also tried Code Blocks back in the day and VS was just a better choice. Maybe things changed, never went back.
2nd,
Visual Studio used to be solely C++ environment years ago. When C# appeared, it was added to VS.
3rd,
Check, if you can lower optimization and tweak other settings, it might speed up your compilation iterations. There is also Incredibuild, which speeds up build times.
4th,
If you debug, optimize, measure performance and such, the simple text editor just won’t do.
I remember when Visual Studio had separate products for each language.
VS has had C going back to the 80’s, C++ later added, and C# added sometime in the 2000’s after it was created… VS has become much more language independent over this 30-40 years, also. Frankly, Visual Studio Code is probably the better product, though, but for certain UI choices that it absolutely blows on.
C0r37py,
Hey, are you using Visual Studio 2022 standard release 64-bit edition for your performance comments? Can you give the Windows Version/ Unreal Engine Version/Visual Studio version/Processor/RAM/SSD size with % full and page size/and video card specs in your performance comparisons?
Also, I believe in 2018-2019 I was using a personal license of Incredibuild that would link 4 computers. Have you reached out to them to see if there is something like that you can use to get started? Just remember it will be slowed by the slowest performing computer you have networked, and faster networking hardware makes difference as well.
For anyone to help you, a mention of the software/hardware/lines of complex code is paramount if the community is to help you improve your build times. Community needs solution boards, maybe your problem helps someone else as well. There is great knowledge in the community. Help us help you by sharing!
According to my system spec, I even don’t need any of the third party accelerators to fast compile.
I have ASUS ROG STRIX GeForce RTX 3060 Tii7 + 32GB Ram 500gb/SSD
I recently realized that Visual Studio is not using the full power of the CPU because it needs Incredibuild, this is very funny having an RTX 3060 +i7 + 32GB Ram + SSD will not help Visual Studio to make the build faster while CodeBlocks has a Plugin can use even GPU to make the compilation super faster.
The Question is why Visual studio not using the full CPU power on the first place and the GPU power will be the next question after getting answer to this question.
My settings claim to use all my cores for building without Incredibuild.
And it sure seems to be doing that Building 37 actions with 16 processes...
Admittedly it’s still nice to build at work with it distributed when you can use potentionally hundreds of processes… but at some point your bounded by UHT, link times and data transfers to those other machines.
And how did you come to that realization? It’s probably the settings MagForceSeven supplied. When everything is in default setup, it most definitely uses all your cores (if you have enough memory to do so, which you may not)
You keep making a lot of claims, but not showing any data, or really telling us anything at all concrete.
VS is not broken.
What sort of i7 are you using? There’s an absolutely massive difference between an i7-4700 and an i7-10700, i know, i just made that leap.
Also, 32gb ram is a bit tight for large compilations.
I will share the data when next time I will use VS for my large projects, but currently happy with CodeBlocks, it needs some manual loadings and after all super fast.
, I tried that to use codeblocks to actually compile the data because it’s very nice to use, you can change the compiler type fast and not get errors, then switch back.
I think you need to have visual studio installed to do that and it’s just like a wire extension from visual studio to code blocks ? Do you actually compile in codeblocks, or you just hit save and hit compile in the editor, you have visual studio installed ?
