Losing hours and days to re-compiling a project when making extremely small changes.

Development Programming & Scripting C++
1

So far I keep encountering insanely long compile times for a basic, barely put together project.

For example here are the following issues that I encounter which ends up resulting in 5-10 hour re-compiles.

  • Deleting a c++ file (in this case include cpp/h)
    • Results often in a total re-compile of the project for unknown reasons. Even when the file wasn’t being used by anything at all.
    • Usually thousands of files.
  • Moving a c++ file
    • Results in a total re-compile of the project, even if the file wasn’t in use anywhere
    • Usually thousands of files.
  • Creating a c++ file
    • This usually isn’t too terrible and the IDE & UHT seem to figure it out. However what happens is;
      • Make the class in UE
      • IDE pops up & ‘live coding’ I guess does a small compile.
      • Then you need to refresh the project in the IDE and close it.
      • Close the editor next
      • Re-open IDE and make your actual changes
    • Re-compile project (THIS in my experience is the ONLY short-lived compilation, meaning it’s usually only a few files, not thousands.)
  • Adding a component via C++ to something that already has a blueprint child in-project
    • It appears that UE doesn’t ever pick up that you’ve added the component
    • Results in wiping everything already compiled in the project trying to trouble shoot why UE doesn’t see the component
    • Thousands and thousands of files being recompiled. No idea why.

So here I am, once again just trying to troubleshoot why UE doesn’t see anything as if it doesn’t exist. That process thus far was;

  • Delete the Binaries folder
  • Delete the Intermediate folder
  • Re-generate the project files
  • Run Compile on the project in my IDE

The new total is now 4205 files. Look, I’ve basically written around 20 files, not thousands. Last time it did this it was around 3100 files or something.

I’ve set the compilation system to use every available ounce of 64gigs of ram and all of my Ryzen 9 processors.

Still I am looking at hours and hours waiting to see, if UE can actually see anything. It’s rather mind-boggling to me to think that anyone, in this day and age, would expect to work like this. Is there some secret super computer that studios have that magically compiles things faster?

Why would my project’s files for compiling magically bloat by a thousand more, when I’ve not added any to that scale?

Watching the compile as I write this, why is it re-compiling things like UnrealEditor-ConsoleVariablesEditorRuntime.dll when I’ve not made any changes to that or any of it in any shape or form?

To me, it looks like it decided to recompile the engine itself, which shouldn’t be the case as I specifically told it to compile the project. Also, the engine itself if I were to recompile it, would be 12000 files and take 24 hours.

I guess I just don’t fully understand the scope here;

So I’m compiling a ‘project’ version of the ‘editor’, but why and how would it change from 3000 to 4000 when I’ve done literally barely anything since the last project compile? Usually my project actually compiles about 1000 files if I delete the binaries & intermediate folder. Which fortunately only takes 30 minutes.

Why am I forced to delete the folders, does UE have that much of a dog-biting-bone issue with ‘ghosts’? Sure seems to.

I guess I don’t understand why when I literally define something specific the UE can’t seem to understand it unless I wipe from orbit and rebuild from scratch. It seems very silly to me.

2

i can add a c++ file, recompile and be back in editor within 5 minutes. My mid range dev computer is about 6 years old. Something is wrong with your setup.

When adding a file thru unreal, give Visual Studio a bit after unreal sets off the compiler and see if it asks to re-load the solution. You shouldn’t need to re-start VS adding a file.

Deleting your Binaries/Intermediate folder will force recompile all your project objects, shouldn’t need a recompile of your engine.

Check thru your build.cs and .uplugin files to make sure they make sense. Try setting up a super basic c++ project and see if you have the same issue there.

Windows system and driver updates can cause a recompile of the entire engine. That gets me every once in a while.

The problem with adding a component to a pre-existing actor in a level is the way unreal saves objects in a project file, when it reloads and tries to re-map the data it fails and can cause all kinds of issues. If you spawn your actors/components dynamically this isn’t a problem. This is just something to be aware of and to work around. TBH this same issue cost me half a day last week even though I have run into it many times before.

3

I hate to say that this is either a local setup or a user problem because neither I, not any of my colleagues have ever encountered this type of behavior when building projects. Perhaps a few pictures of the UI that you’re interacting with in your IDE. And of the Solution Explorer window for your project.

How are you choosing to build when you do it? From Visual Studio, there are some regular C++ options that should not be used when building Unreal Engine projects due to how UnrealBuildTool is invoked.

Neither of these things should cause a re-compile of the project. They may recompile more than you expect sometimes (due to the Unity build process) but not the whole project.

This whole workflow is bad. For an Unreal project with C++, you should start with opening up the project in your IDE and running the Editor from there. You’ll still have to close the Editor to add files, but you won’t re-open the IDE every time you make C++ changes. Ideally you should also just make C++ files with the Editor closed. You don’t need to do that through the Editor.

Yeah, that shouldn’t be happening. As long as you’re creating it correctly as a default object, it should get added to existing blueprint children just fine. It always has in my experience.

Yeah, unless you’re using a source build and making changes to engine header files you should not be compiling this many files on a regular basis. It feels silly because it’s not supposed to be working that way. No one else complains because it’s not doing that for us.

4

I take it you’re building from source. Editor projects used to default to Shared. Now they default to unique. That’s the issue. It will rebuild the entire source to match your settings. This will happen regardless for a published build. But for a build that you run in the editor, you don’t need that. Go into your editor’s target.cs file and add this line:

    BuildEnvironment = TargetBuildEnvironment.Shared;

This should fix your issues. You may have to delete your Binaries, DerivedDataCache and Intermediate folders. You’ll have to right click on your uproject file and regenerate project files.

I’d delete the Saved folder as well. You can keep any actual save game files or render queue files in there.

This will cut down your build times to seconds.

One more thing. Make sure your commit size is at least 3x your RAM size. So if you have 64GB, at least 180GB of virtual ram on your C drive is necessary. This is what is used to calculate how much ram is available for each core when building and you want to use all the cores you can. And no, it won’t go into virtual RAM if you have 64GB. It’s just stubborn in its calculations.

2 Likes
5

nuking Binaries+Intermediate every time is what forces the full rebuild. thats why you jump to 3000 files.

normal flow: dont create/delete files through explorer, use editor Add New C++ Class or close editor then gen project files. when adding a component to an actor that already has BP children, make it a UPROPERTY with CreateDefaultSubobject in constructor and compile once, BP children pick it up after reload, dont delete/recreate the component in the level.

also check you arent touching a widely included header — one edit in a base header that everything includes will rebuild thousands via unity builds. use forward declares + .cpp includes instead. and keep Live Coding off for structural changes, it lies about needing Binaries delete.

1 Like
6

Yea that’s what I’ve been doing as one day I created something and didn’t follow my organization plan so then I went to remove it and well, it was a cascade of failures.

On one hand it was good to learn the lesson now to create the files in the editor, on other hand it was rather silly that I lost a whole day because I didn’t put the file in the folder where I wanted it to be.

In this particular case I had done the correct flow of creating in the editor, then going to edit in the IDE. My problem was the component couldn’t be ‘seen’ in the editor at all. So then began a process of troubleshooting and eventually nuking from orbit. Even after all of that, the component still wasn’t showing up on the child blueprint. In any event I ended up manually making the component(s) in the editor because rebuilding the whole character from scratch isn’t going to happen.

@AlienRenders

I do NOT have

I will add that. Thank you for this.

7

FYI, deleting Binaries+Intermediate does NOT cause the source of UE to rebuild. It’ll only cause your own project to rebuild.

8

Yea I know, it’s another reason why I was… sort of confused.

Especially since normally when I build my project it’s about 1k files.

Then last week it magically became 3100 files or so.

And now this time it decided it wanted to do 4300 or whatever.

I’ve made 20 c++ files (40 total including headers)

Which is why I am sort of in a spot where I’m half deciding if continuing in unreal is even worth the effort. I spend more time waiting for things to compile than actually getting anything built.

9

Did you add this to your editor’s target.cs file?

BuildEnvironment = TargetBuildEnvironment.Shared;

If so, then it shouldn’t build thousands of files anymore. Having said that, you may need to build your UE source one last time to put things back in order.

To clarify, deleting binaries+intermediate folders will cause thousands of files to rebuild if you don’t have that line above. If you do have that line, then only your 20 files will rebuild.

1 Like
10

Another issue I ran into a while back with 5.8 is that it doesn’t like it if you have two vs 2022 build tools. So if you have vs 2022 installed along with vs 2026 with the 2022 build tools, it will get confused and keep rebuilding. Make sure you only have ONE vs 2022 build tool. I kept both vs 2022 and vs 2026 installed, but removed the vs 2022 build tools from 2026. I think it’s v143 build tools that you have to remove from vs 2026 if you already have vs 2022 installed. Or remove vs 2022 if you don’t use it anymore.

11

That’s helpful and hopefully it will help people.

In my case this is all fresh installs of vs 2026 and the ue 5.8.1 git hub repo.

12

That’s curious. I’ve never heard of this problem.

In my own experience when doing Engine upgrades I’d often have multiple toolchains installed to build both the upgraded version as well as the current version of the project on the same machine. I never uninstalled older toolchains either. Also I would often have the toolchain I needed for personal projects be different than the version needed for the work project when I would do work on my own laptop.

UBT is supposed to bias to the preferred toolchain, regardless of what other ones might be installed. It does this with the linux cross-compile toolchains too.

13

Wake up today with a whole new set of magical problems, at this point I’m shocked that anyone would pay a dime for this engine.

  • Character file no longer saves.
    • No there’s no other versions of UE running anywhere
    • No the file isn’t locked or read-only
  • Visual Studio 2026 forced an update even though I’ve been postponing it (a whole week)
    • When to run the editor
    • Now the whole project is re-compiling 4500 files (magically grew another 300 files somehow, still haven’t added any new files to it.)

I’m serious, it is beyond me that anyone in any shape or form would pay for this engine. It’s nothing but a janky mess, I lose so much time just waiting to see if its going to work to “oh it’s not working today”.

Changing all of the settings to get the thing to compile faster hasn’t really improved anything, instead of 12 hours to compile it takes two hours. In the meantime I get to stare at the wall and wish I was actually getting some work done.

Alas, no, it’s an UNREAListic dream it appears.

14

That’s a Visual Studio issue. Not unreal engine. I know it’s frustrating, but if the compiler updates, it’s going to want to rebuild everything. And that applies to all C++ projects, not just unreal.

If you don’t want to rebuild UE, why not just use the binaries?

If you do finish building UE, can you build your project without it building the engine? Once you are successful at doing this, then things will take seconds to build.

15

Ah, well this is what I get I suppose for not paying for Rider.

Trying my best to do everything with little to no cost.

I disabled the updates in VS but it still tries to hammer it home constantly.

After the recompile the character asset seems to be back and saving fine. I can’t think that VS would be holding that uasset file hostage, maybe it was?

16

Rider is free now, at least for indies

17

Depending on what the root cause is for this, switching to Rider won’t help.

Regardless of the IDE that you use, UnrealBuildTool is invoked to do the compilation which uses the installed MSVC toolchain. If something is invalidating those files and causing them to be recompiled, switching to Rider won’t necessarily make any difference. And updates shouldn’t cause a full rebuild as long as the preferred toolchain is installed.

You should post a log from one of your builds.

Because 99% of users aren’t encountering this. In 12 years of working with Unreal (3, 4 & 5), I’ve never had this problem. Nor have any of my colleagues. There’s some detail that’s causing this to happen for you that we identify and you’re not able to tell us (not maliciously, you just don’t realize it’s a detail that matters).

I’m not claiming it’s perfect. But in this particular aspect, UBT is actually a pretty nice step up from cmake bs.

2 Likes
18

try rider and open uproject directly instead of sln, this is better way

19

Are you on a corporate network with security stuff like Trellix or ZScalar? They absolutley destroy the performance of Unreal Editor, Visual Studio, and pretty much everything else. :expressionless_face:

20

Nope.

Well VS 2026 has removed the option to update “never”. So now every Tuesday, I’m forced to update and re-compile what is apparently now, 4205 files or something for my puny little project.

I mean… I just finally added a single attack. I spend more time trying to get the thing to let me do things than actually getting to make things.

  • VS 2026 forces you to update no matter what every Tuesday when they update.
  • The immediate pressure to make me update, is uasset files become secretly locked I can no longer save them after an edit.
  • After running an update, I am forced to do egregiously long compiles.

I will get around to posting what was asked for to see if that will help. I am seeing a ton of junk I know I don’t need, like android hoopla and iphone sash and I have no plans to deliver to those platforms, but it wasn’t much of a choice when I setup the project; things are pretty convolulted in VS 2026 for the setup; I had to manually edit some configuration files just to get it to work with 5.8. So I’m sure there’s a few kitchen sinks in there that don’t need to be there.