Compile-Time Improvements in LLVM 23

[u/TheCrush0r]

https://aengelke.net/llvm23-ct.html

[u/matthieum]

LLVM 23 has seen substantial compile-time improvements of -6.75% in -O3 builds.

Anyone would jump at a 6.75% performance improvement. Right?

What I find particularly interesting here, is that looking at the breakdown, most of the optimizations are tiny. Apart from the DenseMap change (-1.27%), it's mostly -0.x% improvements, and some are even -0.0x%!

Imagine working for hours, only to shave off a measly 0.02%. It feels pretty unrewarding... no? And yet, relentlessly chipping at it -- 0.02%, 0.03%, or 0.04% at a time -- over the release cycle, at the end you get to a massive 6.75% speed improvement.

My deep thanks to the tireless contributors, who make development faster down the line.

[u/Matemeo → u/matthieum]

At a previous job our big headline internal project was a heavily modified fork of LLVM/Clang, where it had become more of a runtime than just a compiler. Anyway, my first task there was reducing compilation times of the generated tests/applications. Me and another spent nearly 6 months methodically profiling, researching, testing and eked out about a 10% reduction in the portions of our CI pipeline using our version of the compiler. And a pretty good chunk of it was optimisation of our modifications and cheating a bit knowing certain passes could be removed or heavily hinted.

All that to say, I agree with you 100%. Optimization of any mature product can be grueling work but something as large and complicated (and very well written/maintained imo) as LLVM will break most people before you see the light at the end of the tunnel.

This post sharply brought back some very interesting but tough work from a good while ago.

[u/fortsnek274]

Did they try using modules? /s

[u/TheCrush0r → u/fortsnek274]

You might be joking, but the answer is yes. They ended up using precompiled headers instead: https://discourse.llvm.org/t/rfc-use-pre-compiled-headers-to-speed-up-llvm-build-by-1-5-2x/89345

[u/fortsnek274 → u/TheCrush0r]

And they have tried clang modules, which would be rather odd for a compiler of a language that has standard modules.

The poster says (clang?) modules "kill parallelism." I wonder what was modularised. Should probably only do it for what they're creating PCHs for. The std lib, core functions.

• Make Clang 3x faster. I see no fundamental reason why parsing C++ has to be this slow, but this is very unlikely to happen (I’m not going to write a new C++ parser and I believe Clang still has the trend of becoming slower over time).

• Rewrite LLVM in a language that compiles faster… haha, just kidding.

Yeah. What's needed, a template cache? Somebody at https://discourse.llvm.org/t/cache-template-instantiations-across-tus-proposal/86497 thought of that, but then decided it wasn't worth it.

They have DLL'ified the Windows build though, apparently. That would help if I ever need it.

[u/jetilovag → u/fortsnek274]

The explicit limitation of exported symbols to the public API is very much welcome and is what enables DLL builds on Windows. Release binaries can be much smaller and as a bonus also lights up plugin support on Windows. AdaptiveCpp can finally ship as a plugin, not a full-blown toolchain.

[u/fortsnek274 → u/jetilovag]

I'd also love it if VS used it so downloads wouldn't be as gigantic.

[u/gracicot → u/fortsnek274]

To be honest, switching to named modules in a codebase of that scale must be quite the undertaking

[u/fortsnek274 → u/gracicot]

Not really, you only need to import ext libs, std, and core stuff for best build perf. It would be great if compilers could do it automatically, but MSVC only seems to be able to translate to header unit imports rather than named module imports. Or rather, you'd probably need to translate to a header that does the import and brings in macros.

[u/pjmlp → u/fortsnek274]

Actually it isn't that odd, the two former big contributors, were responsible for header modules, and at least in what concerns to Apple's own clang downstream, those are the ones that matter.

They are used for Objective-C and Objective-C++ modules, interop between Objective-C and Swift, and newly Swift and C++.

They are also used by the new build system improvements introduced about two years ago, explicit modules building.

Finally if you go to Apple's XCode support page for ISO C++, you will notice there aren't any rows for C++20 modules, nor import std, where one would expect to at least have them listed with no/XCode version instead.

And in what concerns Google, they are more busy with other languages to care about C++20 modules, while clang header maps do their job already.

[u/sweetno → u/TheCrush0r]

I've heard PCHs interfere with ccache and friends. Is this ever a concern?

[u/JustCopyingOthers → u/sweetno]

I have experienced that. It is hard to get high ccache hit ratios in a CI environment that builds multiple versions though as different dependency versions invalidate prebuilt code that would otherwise be identical. So PCH does have a place.

[u/_Noreturn → u/TheCrush0r]

Will unity builds come sometime

[u/LongestNamesPossible → u/_Noreturn]

What do you mean? Just make some fat compilation units yourself and get your number in the range of the cores on your computer.

[u/_Noreturn → u/LongestNamesPossible]

building llvm with unity builds doesn't work.

[u/VoidVinaCC → u/_Noreturn]

Yeah its odd considering those would probably be the biggest improvement....

[u/_Noreturn → u/VoidVinaCC]

I mean it does make sense as llvm uses using namespace clang in each source file instead of opening a namespace like others do to catch link errors quicker, but this costs the ability to do unity builds as it is basically like doing a using namespace in a header file which could cause issues.

also unity builds will also act like a kind of poor man lto that is faster to compile so it is a win

[u/VoidVinaCC → u/_Noreturn]

unity builds are free lto, faster builds, a lot less memory usage, a lot less disk and os stress.. at the cost of... having a cleaner codebase..? its ONLY wins!

[u/ABlockInTheChain → u/VoidVinaCC]

at the cost of... having a cleaner codebase..? its ONLY wins!

The cost is completely foregoing all TU-local constructs.

Personally I think that's fine because I never used TU-local anything before so there wasn't much to give up when I started experimenting with unity builds, but apparently some project lean on those very heavily.

[u/VoidVinaCC → u/ABlockInTheChain]

Ive converted various (and big) codebases to unity-capable ones before, its not much of an issue tbh

[u/_Noreturn → u/ABlockInTheChain]

This isn't even true, you can have TU local stuff with help of cmake UNITY_BUILD_UNIQUE_ID

cmake set_target_properties(myTarget PROPERTIES UNITY_BUILD "ON" UNITY_BUILD_UNIQUE_ID "UNIQUE" )

then you can do this in your source files

```cpp namespace UNIQUE { static int x = 1; }

int func() { UNIQUE::x = 1; }

// another translation unit namespace UNIQUE { static int x = 1; }

int func2() { UNIQUE::x = 1; // different x. } ```

internally cmake does this

```cpp

define UNIQUE _19389493

include "cppfile1"

define UNIQUE _829283948

include "cppfile2"

```

[u/_Noreturn → u/VoidVinaCC]

only "loss" is slower incremental builds, which isn't even 100% true, since if you edit a header unity builds will be faster than normal builds. and if they open a namespace instead of doing a using namespace it should be possible and I think it could be automated ad well.

```cpp // they do this

using namespace clang;

void foo(SomeClangType) // impl {

}

// they should do this for unity builds

namespace clang { void foo(SomeClangType) {

}

} ```

also allowing unity builds will bring more contributors, I don't contribute to clang although I would want to as I have very very long wait times that absolutely kill my motivation due to my weak laptop unity builds would help a ton

[u/VoidVinaCC → u/_Noreturn]

its just really painful to think how much compute and time is wasted on compiling/processing the same headers, templates, functions, ... a billion times and a pch generally doesnt change that either. unity build are the ONLY actual functional and efficient way of building c++ today. modules dont count because they dont work most of the time and require a lot more work to get spec compliant

[u/_Noreturn → u/VoidVinaCC]

Try thinking how much time is spent on computing useless strlen calls when you already know the string length :p

But yes I agree, unity builds are a blessing and are the fastest way to build, they surpass pch and modules all together

[u/VoidVinaCC → u/_Noreturn]

Not as bad due to cachelines and throughput of current hw, but yeah :D

[u/btc_maxi100]

when is the release date ?

[u/encyclopedist → u/btc_maxi100]

LLVM 23.1.0 is scheduled to be released on 25 Aug 2026, in two days.

[u/_Noreturn]

I wish I understood how this works but awesome work

[u/TheRavagerSw]

It is very buggy though, unless your are contributing you should disable PCH via cmake

[u/babygnu42 → u/TheRavagerSw]

If you have any concrete bug, please open an issue on GitHub so that people get a chance to fix it!

[u/Senior_Care_557]

interesting

[u/Fine_Evidence_8130]

Ä,,,,£££ ,,,,, ££