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@boostpro.com> 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