undefined

points

[-]

> II’d argue that a single unity blob with one compiler invocation isn’t a fair comparison and that when you made a token effort to configure the unity build you saw a 2x speed up.

Most certainly an unfair comparison; I did not know that "unity build" also referred to a hybrid setup. I've only seen people advocate for a single translation unit approach, and that's always just plain slow.

Personally I'll almost always prefer faster incremental compilation; thankfully my work's clean builds only take 30 seconds.

> I’d also love to see what raddbg would be like if we split it into even 4 compilation units

Should be a minimum of 32x faster just building in parallel with our hardware ;)

Unfortunately raddbg suffers from unity-build-syndrome: It has headers but they're missing definitions, and .c files are missing includes.

by maccard223 days ago|

parent|

[-]

If my clean builds were 30 seconds I’d prefer incremental performance too. Our precompiled headers take longer than that. A clean ue5 editor build with precompiled headers, adaptive unity builds and optimisations disabled takes 20 minutes or so. Incremental changes to game projects are usually prettt quick - under 5 seconds or so (which is fast enough when the whole thing takes 30+ seconds to boot anyway.

> Unfortunately raddbg suffers from unity-build-syndrome: It has headers but they're missing definitions, and .c files are missing includes.

We run a CI build once a week with unity disabled to catch these issues.

> Should be a minimum of 32x faster just building in parallel with our hardware ;)

My experience here is that parallelism is less than linear and avoiding repeated work is super-linear - there’s a happy medium. If you had 128 files and 32 cores it’s probably fast to compile in parallel, but likely even faster if you can just dispatch 32 “blobs” and link them at the end.