Will modules make template compilation faster?

Question

Will modules make template compilation faster? Templates (usually) have to be header only, and end up residing in the translation unit of the #includer.

Related: Do precompiled headers make template compilation faster?

Answer 1

According to modules proposal, from the very paper you cited, it's the first of the three primary goals for adding modules:

1 Introduction

Modules are a mechanism to package libraries and encapsulate their implementations. They differ from the traditional approach of translation units and header files primarily in that all entities are defined in just one place (even classes, templates, etc.). This paper proposes a module mechanism (somewhat similar to that of Modula-2) with three primary goals:

• Significantly improve build times of large projects
• Enable a better separation between interface and implementation
• Provide a viable transition path for existing libraries While these are the driving goals, the proposal also resolves a number of other longstanding practical C++ issues (initialization ordering, run-time performance, etc.).

So, how can they accomplish those goals? Well, from section 4.1:

Since header files are typically included in many other files, the growth in build cycles is generally superlinear with respect to the total amount of source code. If the issue is not addressed, it is likely to become worse as the use of templates increases and more powerful declarative facilities (like concepts, contract programming, etc.) are added to the language.

Modules address this issue by replacing the textual inclusion mechanism (whose processing time is roughly proportional to the amount of code included) by a precompiled module attachment mechanism (whose processing time—when properly implemented— is roughly proportional to the number of imported declarations). The property that client translation units need not be recompiled when private module definitions change can be retained.

In other words, at the very least, the time taken to parse these templates is only done once instead of N times, which is already a huge improvement.

Later sections describe improvements for things like explicit instantiation. The one thing this doesn't directly improve is automatic template instantiation, as section 5.8 acknowledges. Here all that can be guaranteed is exactly the same benefit you already get from precompiled headers: "Both modules Set and Reset must instantiate Lib::S and in fact both expose this instantiation in their interface file." But the proposal then gives some possible technical solutions to the ODR problems, at least some of which also solve the multiple-instantiation problem and may not be possible in today's world. For example, the kind of queried instantiation suggested has been tried repeatedly and it's generally considered too hard to get right with today's model, but modules might make it feasible. There's no proof that it's impossible to get right today, just experience that it's hard, and there's no proof that it would be easier with modules, just the plausible possibility that it might be.

And that fits with a general implication that's never quite stated in the proposal, but is there in the background: Making compilation simpler means we might get new optimizations in the process (directly, because it's easier to reason about what's happening, or indirectly, because more people work on the problem once it's not such a huge pain).

In summary, modules can and will definitely make template compilation faster, if for no other reason than that the template definitions themselves only have to be parsed once. They may allow for other benefits that are either impossible or more difficult to do without modules, but that may not be guaranteeable.