Re: [boost] So.... what are we going to do about modules?

On Tue, Apr 5, 2022 at 8:58 AM Niall Douglas via Boost < boost@lists.boost.org> wrote:

On 05/04/2022 14:11, René Ferdinand Rivera Morell via Boost wrote:

...

On Tue, Apr 5, 2022 at 7:54 AM Horváth V. wrote:

...

On 2022. 04. 05. 14:46, René Ferdinand Rivera Morell via Boost wrote:

...

I highly doubt it.

Something I noticed is that a lot of people raise compile times as a reason they don't want to use Boost and modules supposedly help with that.

The gains to be had depend highly on both the code structure and project structure (both of the modules and the user code). The gains are almost entirely in the re-parsing. I.e. they are not going to help much on the template instantiation. Which, IIRC, is the larger of the compile time complaints for Boost. But someone would have to do some performance analysis of a good size project that uses Boost in a compiler that supports such perf inspection to really know.

To be specific here, what are the gains of Modules over Precompiled Headers, which Boost.Build already supports?

Niall's fairly confident answer: little to none, and perhaps even a regression as ODR resolution is time expensive.

It depends :-) Assuming that you smartly organize and engineer your modules they will end up with shorter compile performance for certain compile contexts. I think that's sufficiently qualified ;-) ... The real answer is that precompiled headers need to reparse the entire TU context at any change in that TU context. While modules isolate the reparse to the "headers" specific to the modules. Hence if properly used there will be less reparsing with modules. But it's definitely not trivial or straightforward to implement that proper module structure. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net