Re: [boost] Boost.Generic, C++0x Concepts, and C++1y Concepts

Subject: Re: [boost] Boost.Generic, C++0x Concepts, and C++1y Concepts
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-09-28 05:18:33

On Thu, Sep 27, 2012 at 6:38 PM, Matt Calabrese <rivorus_at_[hidden]> wrote:
> On Thu, Sep 27, 2012 at 9:11 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>wrote:
>
>> Yes, of course. That's a big difference with respect to Boost.Contract
>> where the macros are used in the user code so I can't pre-compile
>> stuff in the lib to speed up things. (Using pre-compiled headers in
>> the user code reduced re-compilation time of the users code from x30
>> to x2 but users still have to wait a long time when they compile their
>> headers for the 1st time and if they significantly change their
>> contracts as many of the pre-compiled header will need to be
>> re-compiled.)
>
>
> Yeah, that's a truly enormous speed-up. It's too bad preprocessor code is
> not that easy to profile. I don't know about you, but it was sometimes a
> bit of a guessing game and trial-and-error for me before settling in on the
> approach that I ended up with.

Honestly, I didn't even try to profile/optimize Boost.Contract pp code
yet. I'm not sure if I'll try to count the number of macro expansions,
the depth of macro expansion, etc... maybe using clang or Eclipse... I
don't know yet.

For a project with 122 files and 15,471 lines of code, Boost.Contract
increased compilation time x26 when all contracts are enabled and x2
when contracts are disabled (with respect to the same code without the
Boost.Contract macros which is the baseline at x1):

http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp_0_4_1/doc/html/contract__/contract_programming_overview.html#compilation_time_warning_anchor

In both cases contracts enabled/disabled, the parsing macro code it
there so _maybe_ that's not where the bottle neck it. When contracts
are disabled the macros expand just to the function declaration
signature. When contracts are enabled the macros expand to the
contract checking code so maybe the bottle neck is in expanding this
code (pp) and then compiling it (compiler). But this is just
speculation, I need to profile and optimize Boost.Contract pp and
non-pp code.

--Lorenzo