No, that shouldn’t be the case at all. When you compile from source, the UE4 codebase is only compiled once, unless you make changes to it which is unlikely if you’re still learning how to use it. If you were to recompile everything, that would take much longer than 30 seconds. The compiler will just link with the libraries directly without a recompile, which is exactly the same as the precompiled libraries Epic supplies with their binary distribution.
So I’m not sure what meant by that.
Generally if you make changes to headers it’s going to take more time to compile. For reference ShooterGame takes 43 seconds to compile after a smaller change in a CPP file (headers usually take longer) on my rig. (i7 Quad, mechanical HDD)
With that said, they’re working on decreasing build times and they’ve said 4.3 is a little bit faster than 4.2. The difference between 4.2 and 4.0 was huge. So hopefully it’ll only get better. I try to avoid making smaller changes in C++ and try to expose those to the editor as variables. This way iteration is much faster, but if you’re changing gameplay code then I guess you’ll have to live with it or buy an SSD. It should help some.
Edit: I also try to stay away from hot recompilation. It usually breaks for me (even if I’m only changing a variable), and isn’t much faster.
What i meant was just avoid the full source if you dont need it.
As OP is stile lerning C++ i tought it best to leave out any “vierd” words/ names.
And just help OP got setup with the binarys and start from there.
Agreed, using the source binaries is a better start even if it isn’t any faster to compile against.
Out of curiosity, what version are you guys testing on? I haven’t gotten around to try 4.3 yet but the improvements between 4.0 and 4.2 are huge, so hopefully they’re not done yet.
I’m holding off for the official 4.3 release rather than the preview, so I’m using 4.2.1. I see what you’re saying, Stefan. But it is fact that compile times for the same game using compiled-by-me UE4 source VS UE4 binary amount to 36 seconds and 13 seconds, respectively. Whatever the case may be, my compile times with the binary are much, much faster.
I hear you Jared, and it’s very interesting since there shouldn’t be any difference. I know the optimization stage takes a lot of time when building release, so maybe there are differences there. Not sure what’s going on, maybe someone can chime in from Epic.
We are working on compile times a lot right now at Epic! There is a big push for faster iteration, you will see some of these changes in 4.3 but we have a lot of work yet to do. I’d be happy to go into detail for those who are interested, but in short we are dramatically shrinking the number of engine header files that need to be included in every game source file as well as optimizing Unreal Build Tool startup times. We’re also working with Microsoft to profile compile times with UE4 and hope to further optimize build performance using that data.
Meanwhile, incremental compile times when changing only a few game source files should actually be very fast (6 seconds or less). This is because the precompiled header that was generated for your game module was cached and will be reused on subsequent compiles. The only code that that compiler will redigest is your actual game source file, not the included header files, which usually completes very quickly! (less than a second.)
If you go and change a “global” header file for your game, then Unreal Build Tool will need to recompile the precompiled header for your game, and you can expect a slower build that time. It can help to only use #includes in the .cpp files that actually need them, and to avoid creating a massive game header file that includes all of your other header files. Even though that will be convenient for a programmer, it can demolish your productivity if you are constantly changing game header files.
We also have some baseline overhead as Unreal Build Tool starts up, which is scanning your hard drive for source files and building the dependency graph. If you are working with a build from GitHub, the dependency scanning will take longer because Unreal Build Tool will try to determine if the engine itself needs to be recompiled. We are working to optimize this UBT startup time, but it should still not be more than a few seconds for a normal game project.
For example, if I rebuild VehicleGame (from the Vehicle sample on the Marketplace), make a change to VehicleGameMode.cpp, then perform a normal build (Development Editor configuration), the average time to complete is only 6 seconds.
If you’re using the source from GitHub, rebuilding the entire Unreal Engine obviously takes a lot longer. I can rebuild 4.3 on my MacBook Pro in 16 minutes. In order to achieve this, I set my ProcessorCountMultiplier setting (in BuildConfiguration.xml) to 2.5. This setting will control how many translation units can be compiled at the same time. By default ProcessorCountMultiplier defaults to 1.0, which means 100% of your total number of processors (one compiler invocation per processor.) However, many computers have multiple hyperthreaded cores, which means it can be advantageous to set ProcessorCountMultiplier to 2.0 or higher to get the fastest possible rebuild times. This will of course use more battery life and make multitasking slower, so it is a trade off that you need to experiment with.
Computer specs will of course be a factor and having an SSD or RAID will help if your disk cache is cold, but in general the iterative compile times are mostly affected by what I described above, and more RAM or a new HDD will not help much. More cores can help for rebuilds, but not for iterative builds.
I wanted to also point out that the information above (originally from my AnswerHub post) is now out of date. Unreal Build Tool will force generation of precompiled headers and non-unity builds for “smaller” game projects (as configurable with MinGameModuleSourceFilesForUnityBuild) in your BuildConfiguration.xml. I set it up this way so that you wouldn’t have to worry about tweaking out settings to get fast iterative compiles on small projects or sample games. Larger projects usually see the real benefits of unity-based compiles and no-PCH compiles, so we tried to make it automatic.
Thank you so much for chiming in, Mike! I really appreciate it.
I should clarify that now the biggest stop-gap in the pipeline isn’t compile times, but rather the editor’s loading sequence. I count them together because it’s necessary to close the editor to make changes to the code. To be honest, the compile times with the binary build amount to about 5 seconds. The load is just under 10 seconds. At this point, I’m pretty satisfied with how long the process takes, though I would of course prefer faster times if you can muster them!
I gotta say, I’m loving Epic’s community outreach. Punches UT square in the jaw.
My biggest issue with build times (after initial builds of course:) ) is the check for UBT changes prior to compilation. I cannot complain as my compilation times are between 11 and 25 seconds. Full Iteration times, including editor load times, are not that important to me. If I have a problem it shows in compilation errors(syntax) and not logic errors.
