Boost logo

Boost :

Subject: Re: [boost] [phoenix] compile-time performance
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-09-13 16:01:51


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.

HTH,
Thomas


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk