Boost logo

Boost :

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
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.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at