|
Boost : |
From: René Ferdinand Rivera Morell (grafikrobot_at_[hidden])
Date: 2022-04-05 14:37:17
On Tue, Apr 5, 2022 at 8:58 AM Niall Douglas via Boost <
boost_at_[hidden]> 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. <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. 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk