On Mon, May 16, 2011 at 7:22 AM, Eric Niebler <e...@boostpro.com> wrote:
> On 5/15/2011 9:19 PM, Thomas Heller wrote:
>> Today I experimented a little bit with phoenix and proto.
>> My goal was to decrease the compile time of phoenix. When I started the
>> development of phoenix, Eric advised me to use proto::basic_expr to reduce
>> compile times.
>> Which makes sense giving the argumentation that on instatiating the
>> node, basic_expr has a lot less functions etc. thus the compiler needs to
>> instantiate less. So much for the theory.
>> In practice this, sadly is not the case. Today I made sure that phoenix uses
>> basic_expr exclusively (did not commit the changes).
>> The result of this adventure was that compile times stayed the same. I was a
>> little bit disappointed by this result.
>> Does anybody have an explanation for this?
> Impossible to say with certainty. I suspect, though, that your use case
> is different than mine or, say, Christophe's. With xpressive or MSM,
> compiles weren't effected by pre-preprocessing, which shows that we're
> hitting limits in the speed of semantic analysis and code gen (possibly
> template instantiation). Pre-preprocessing sped up Phoenix, which shows
> that you're more hamstrung by lexing. The choice of either proto::expr
> or proto::basic_expr doesn't matter for lexing because they're both
> going to be lexed regardless.
> I know when I introduced basic_expr, I ran tests that showed it was a
> perf win for xpressive. But it was a small win, on the order of about
> 5%, IIRC. YMMV.
You might get even faster. I noticed some places in proto that still
instantiate a proto::expr.
That is in the creation of operators (the lazy_matches in
operators.hpp) instantiate a proto::expr. And the generator of
basic_expr is the default generator which instantiates, when called a
proto::expr as well. Not sure if that may actually matter
proto mailing list