[boost] Re: Spirit and slow compile (from gmane.comp.lib.boost.devel)

From: Joel de Guzman (djowel_at_[hidden])
Date: 2003-01-14 23:45:24

----- Original Message ----- 
From: <vincent_finn_at_[hidden]>

> Hi,
> 
> I was talking to you on the boost newsgroup about spirit being slow to compile
> Here is a standalone section of code, it'll compile but you can't do anything with it
> The compile takes about 15 mins on my machine 
> (We are using spirit for a second file but that is smaller and only takes a minute or two)
> 
> The Spec of my machine is P3 833, 512M RAM 
> I'm using NT4 SP6a and VC6 SP4
> 
> I split it into a lib and it works fine so the problem is less crucial than it was! 
[]
> I have a feeling that the Grammar is just big so it's slow and there may not be
> any getting around that but let me know if you see anything we are doing wrong

[]

Indeed! I counted 25 grammars. Wow I'm amazed, some grammars are
quite elaborate, even :-)

After taking a peek at the grammars, I see one minor and one
major code tweaks that should improve both the actual code size 
and compile time speed.

minor: use chlit<> or strlit<> rather than rule<ScannerT> whenever possible.
(e.g. m_CommaToken)

major: I see lots of code duplication. It would be best to factor out common 
grammar definitions into base definition classes. Example:

    template<class ScannerT>
    struct basic_definition
    {
        template<class GrammarT>
        basic_definition(GrammarT const& self)
        {
            // common definitions
        }
    };

Then subclass your grammar definition from this. 

    struct my_grammar : public spirit::grammar<grammar>
    {
        template<class ScannerT>
        struct definition : basic_definition<ScannerT>
        {
            typedef basic_definition<ScannerT> base_t;
            definition(my_grammar const& self)
            : base_t(self)
            {
            }    
        };
    };

It would help a lot to factor out the common grammars this way. You
can even use multiple inheritance where necessary. 

I hope this helps. I took the liberty to re-post this to the list in the hope
that this simple tip might be useful to others.

BTW, in the near future, productions such as:

    r = a | b | c | d | e...

where the alternatives have unambiguous prefixes, example:

    a = "LINEDESC:" >> ...
    b = "PAINTDESC:" >> ...

can be optimized through Spirit style syntactic predicates. 

Ahh, finaly BTW,  you do not need to wrap str_p("...") inside
a lexeme because strlits are implicit lexemes.

Regards,
Joel de Guzman
joel_at_[hidden]
http://www.boost-consulting.com