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

From: Daniela Engert (dani_at_[hidden])
Date: 2022-04-05 14:56:34

Am 05.04.2022 um 15:11 schrieb René Ferdinand Rivera Morell via Boost:
> On Tue, Apr 5, 2022 at 7:54 AM Horváth V.<friendlyanon__at_[hidden]>  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.

Partially true.  During the compilation of the module interface unit, 
the following is done:

1) all parsing. That alone is a big win, in particular with Boost and 
its boatload of includes.

2) all name lookup that can be done in translation phase 7 is performed. 
In addition, all template instantiations that can be done during the 
compilation of that TU are done.

3) all overload resolution within the overload sets formed in 2) is done.

The less unsolicited unqualified name lookup is asked for by the source, 
the more work can be shifted to the one-time compilation of the module 
interface. I've seen too many template-heavy libraries in my life that 
seem to be totally unaware of that. The split between visibility of 
names and reachability of semantic properties is all but irrelevant in 
the traditional header world but plays a vital role in the modules world.

>   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.
>
>
Ciao
 Â  Dani

-- 
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5