Re: [Boost-users] Max Boost Fusion tuple parameters

Subject: Re: [Boost-users] Max Boost Fusion tuple parameters
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-06-14 14:38:12

On 06/14/13 09:08, Larry Evans wrote:
> On 06/14/13 04:39, Slava wrote:
>> On Thu, 13 Jun 2013 14:27:30 +0200, Larry Evans
>> <cppljevans_at_[hidden]> wrote:
>>
>>> It also appears that when TUPLE_SIZE >=100,
>>> compile time goes up linearly.
> 
> I think that linear remark was wrong.  It goes up
> by a factor of about 2 between 100 and 200 and
> then by another factor of 2 between 200 and 300.
> That's exponential IIRC :(  Of course I could be
> misunderstanding again.  It happens :(
> 
>>
>>
>> Take a look at memory usage either, as soon as it starts swapping, it's
>> far from linear. Your peers will curse you for this code. CDT indexer

Yes.  Looking at the performance monitor as it was compiling
TUPLE_SiZE=500 showed almost all the memory was used and, IIRC,
about 40% of swap.

>> (eclipse) takes a lot time and memory on such constructs.
>> The size of the produced binary (due to debug info for all these small
>> inlined internal helper functions) must not be forgotten. It's hard to
>> justify half-Gb executable to the colleagues.
>>
>> -- Slava
[snip]

Using the slim::accumulate template instead of using
python to generate the summation code doesn't make
much difference:

tuple_size compile_time
  10         2.01
  50         3.37
 100         6.26
 200        18.51
 300        43.79
 400       109.28
 500       195.42

Attached is the driver.

I did try to eyeball a fit with qtiplot which showed:

  compile_time = 12*2^(max(0,tuple_size-100)/100)

looked quite similar at tuple_size>=100.

--Larry