Re: [boost] [phoenix] compile-time performance

Subject: Re: [boost] [phoenix] compile-time performance
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-09-13 19:23:35

On 9/14/2011 4:01 AM, Thomas Heller wrote:
> On Monday, September 12, 2011 11:38:44 PM Eric Niebler wrote:
>> On 9/12/2011 4:45 PM, Thomas Heller wrote:
>>> On Mon, Sep 12, 2011 at 8:54 PM, Eric Niebler <eric_at_[hidden]> wrote:
>>>> On 9/12/2011 4:06 AM, Thomas Heller wrote:
>>>>> FWIW, there are some unit tests that outperform the compile times of
>>>>> Phoenix2 (with gcc), the current bad hit on compile times seem to
>>>>> only occur with let, lambda and switch/case expressions.
>>>>
>>>> This /suggests/ to me that the core of Phx3 is sound, but that the
>>>> implementation of let, lambda, and switch are heavy. But I'm not
>>>> blaming
>>>> Thomas. I'm just suggesting a logical place to begin an
>>>> investigation.
>>>
>>> FWIW, i experimented with different implementations, I even almost
>>> identically (as far as i could) copied the phx2 implementation.
>>> For the implementation right now I have several suspects. First of
>>> all, i think the code of the mentioned parts is very ugly (both of V2
>>> and V3). Second of all, there some pretty severe type transformations
>>> going on, repeated calls to fusion::make_map etc. I am absolutely sure
>>> that there is quite some space for improvement.
>>
>> <looks on trunk>
>>
>> fusion::make_map doesn't appear in the phoenix code anywhere. I see
>> fusion::map appears in scope/detail/make_locals.hpp, but that header
>> doesn't seem to get included from anywhere except itself, AFAICT. So,
>> uh, what's up with that?
> 
> My appologies ... that file is a left over from one of my older 
> implementations. After looking at the code i can explain what's going on.
> So, first of all there is scope/local_variable.hpp. This file includes the 
> definition of the locals that is: it is hooked up in the custom_terminal 
> mechanism i inventented to also recognize reference_wrapper. Second are the 
> definitions for the is_nullary meta function. Third is the include of 
> scope/detail/local_variable.hpp which is responsible for the lookup of local 
> variables. which is basically just copied from phoenix V2.
> Now there is let and lambda, which are more or less independent of the local 
> variables except for the lookup. Now, let shouldn't be so bad ... the only 
> thing that might hit badly is the local lookup (no real proof though ...). 
> lambda is bad, compile time wise, cause it generates two proto expression 
> trees, once the lambda itself, and then after the first evaluation round.

Here are my current timings:

vc 10	
let phx2	4.2
let phx3	10.9
lambda phx2	4.7
lambda ph3	30.1
switch ph2	4.2
switch phx3	6.1
        
g++	
let phx2	2.9
let phx3	2.9
lambda phx2	2.8
lambda ph3	4.8
switch ph2	2.5
switch phx3	2.2

I think we should concentrate on lambda as it is the worst
hit of all especially for MSVC. As you noted, some tests
are faster due to the recent CT-performance tweaks you did
for Phoenix3 at least on g++. That is evident on e.g. switch.
The others are still reasonable (e.g. let) but hopefully
can be improved on MSVC.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com