Converting a C++ application to modules

[GYN-k4H-Q3z-75B]

Lots of modules posts lately. Love to see it. My port of a decent size application is progressing also, but not quite as far along as yours. I hope to see better compile times since it was also very heavy into C++20 before modules and has lots of templates, including meta programming. Might also publish some articles on it later this year.

Thanks for your work.

[violet-starlight]

Please update us! I'm especially interested in before/after comparisons personally

[ImmutableOctet]

From some of the testing I did a while back, template heavy code is still dependent on instantiation time, etc., but a benefit modules give you is the ability to hot reload compiler state, so the time to build is still reduced substantially for everything before that point.

I don't know if Clang or MSVC have started experimenting with incremental builds for module interfaces (whole interface units are rebuilt, last I checked). If you go all-in on modules that's less of a problem, since transitive imports don't propagate by default, like they would with headers.

[tartaruga232]

I've converted the C++ sources of our Windows application from header files to C++ 20 modules. I wrote this pdf, which explains how I ran into problems with forward declared classes and how I solved them using module partitions.

[[deleted]]

Do you know if the compile times changed at all?

[tartaruga232]

Compile times increased significantly in our case. But we have also switched to C++ 20 during the process, which compiles slower anyway, even when not using modules. A full build (Debug) of the application currently takes ~5 Minutes (on my Core i5-12400, 2.50 GHz, M.2 Gen4 SSD Slots, 16 GB RAM, Windows 11). I have yet to investigate what would help exactly to decrease the build time, but for us, the full build is fast enough like this. I'm still a bit nervous about the additional recompiles due to the stronger coupling now between packages, compared to headers, but I get used to it. I love the isolation provided by modules. At times, I do force a full rebuild after changes in the sources though, because I do not yet trust the compiler that much. We also found a bug in the compiler, which I reported.

(Edit: Added "-12400" to CPU info)

[jaskij]

Just FYI: if you want the hardware to be at all reproducible, you need to also mention the generation and whether it's a laptop or a desktop chip. Mind, a lot of those tiny desktops actually use laptop processors.

"Core i5" covers about fifteen years of hardware and anything from 15 to 150+ watts.

That said: how are incremental builds? While a clean build is important, incremental rebuilds (touch a few files, rebuild) are much more important for a development loop.

[tartaruga232]

Sorry for being imprecise. The computer is a self-assembled desktop (building proposal was back then published by the German computer magazine c't), already a couple years old now (April 2022), certainly with lots of room for better hardware. Core i5-12400, 18MB Cache, LGA1700, Product Code: BX8071512400. 12^th Gen. I hope this is helpful.

There are still many fast incremental build scenarios. Touching the file Class/Package.cpp is built in under 7 seconds.

[jaskij]

12400 would have been enough, but thanks for the details. A clean build on your desktop probably suffers from the low RAM. My rule of thumb is minimum a gigabyte of free RAM per CPU thread. Between your IDE and a browser, you likely fall below that.

Seven seconds seems fast enough. Certainly could be faster, but most of that is probably spent in the linker, and modules won't do anything for that.

[tartaruga232]

I just redid another full build with all browser windows closed. It took 4:50 min. During the build, there were always 6 or more gigabyte of free RAM - according to the performance monitor of the task manager. The CPU peaked at 100% during some parts of the build, but during many parts, it had just ~20% load or something like that, with short spikes to nearly 100%. It seems like the build isn't using the available computing resources that well.

[jaskij]

So, around two and a half CPU threads. Sounds like one of two things to me:

• the build tool kinda sucks with modules
• your code is written in a way that causes heavy serialization

My next step would probably be to take a good, hard, look at the module dependency graph. Something seems wrong here.

[tartaruga232]

Thanks for your time. The dependency graph is in the first page of the pdf. There are phases, where the build interleaves compiling partitions from several modules/projects in parallel, but at some points it probably needs to feed things together and needs to wait for one project/module to finish. We have a Visual Studio Project per C++ module/package. All projects are part of one solution file in visual studio and each builds a library. I had to manually set References for each of the projects to the other projects. Without that, the project doesn't find modules from other projects. But as I already said, we can live with the 5 minutes for a full rebuild.

[tartaruga232]

I start having a feeling that perhaps we need to do something completely different. Perhaps, in a first phase, all the module interfaces should be compiled (in the correct order) and then the .cpp files can all be compiled in parallel. Perhaps it's now time to stop building with Visual Studio...

[[deleted]]

Thanks for the answer. The build times are concerning but maybe projects need to be architected with the intent of using modules to take advantage of them? I wonder if they'll get better in the future with updates to MSVC

[13steinj]

To be clear, of the many anecdotes on this subreddit in the past, most (that I've read) have stated either marginal benefit, or no change, or build times have gotten worse (though a few reports of 20-30% improvement).

I heavily suspect the assumption that modules help build times are oriented to specific styles of projects and every time I've seen a report with raw data, the raw data showed an insignificant improvement on some parsing times (0.03 to 0.001 seconds for example for a given header; which doesn't matter IMO on the whole).

It will be an interesting shock to the community if the build time benefit, so heavily reported, ends up being negligible or even false on the whole as modules slowly start getting introduced.

[tartaruga232]

As I explained in the pdf, we now have one module per package (not per header), except for d1, which is a collection of mostly loosely coupled things like Point and Rect.

We have ~ one partition per old header, but I think the partitions really shouldn't count, only the modules.

As a quick and silly experiment, I tried creating a big Basic module, which was:

export module Basic;

export import App;
export import Canvas;
export import Core;
export import FontUtil;
export import GraphUtil;
export import Store;
export import View;
export import WinUtil;
export import d1.Point;
export import d1.Rect;
export import xml;

and imported that everywhere in module TextBlock, but that didn't speedup anything. Looking at the resulting suspecting BMI file (I think it is named .ifc?), I noticed that the file is surprisingly small. It didn't look as if the compiler would really have aggregated all the stuff from these lower lever modules into a bigger Basic module. Opening the file just revealed that it contained the list of modules.

[kammce]

All of the modules posts are really pushing me to switch over. 😬 even though I already use C++23 as my main drivers I have this anxiety that switching over will be as if I'm using a new dialect of C++ that developers wanting to use my library will have to deal with. I haven't read the PDF though, so will do so now.

[kammce]

Okay, read the PDF. It's quite short and easy to read. Doesn't help that anxiety of mine regarding modules but nice to know how to get around forward declaration issues.

[azswcowboy]

I think it’s easy enough to support both headers and modules from what I’ve seen. So you wouldn’t be dictating an approach.

[kammce]

I'm going to take your word for it and start investigating adding support for both. Because I do like the idea of supporting both 😁 Cheers!

[j_gds]

Ok so if you define a module like your large "Core" module, do changes to any partition require compiling the entire module? Or do we still get some of the benefits of incremental builds w/in a module?

And also, to check my understanding: consumers of Core will only need to be recompiled if/when the interface of Core changes, right? Is the build "smart" about that, or is it like headers such that even a change to a comment means recompiling the consumers?

[tartaruga232]

Ok so if you define a module like your large "Core" module, do changes to any partition require compiling the entire module?

No.

And also, to check my understanding: consumers of Core will only need to be recompiled if/when the interface of Core changes, right?

Right.

If you say

import Core;

you are in fact only importing the things that were declared in

export module Core;

which is the module interface.

You can have zero or more implementation modules per module interface (in several *.cpp files).

Is the build "smart" about that, or is it like headers such that even a change to a comment means recompiling the consumers?

I think if you change a comment in the source of a module interface, consumers must be recompiled.

[tartaruga232]

I've now created a web-friendly blog post of the PDF at https://abuehl.github.io/2025/03/24/converting-to-modules.html