Re: Horrible compiletimes and memory usage while compiling a parser with X3

Hello everyone,

> Larry Evans <[email protected]> hat am 3. November 2016 um 12:37
> geschrieben:
> 
> (..)
> 
> I'm spitballing here, but maybe a redesign of spirit to use
> virtual functions (or dynamic polymorphism) as well as
> templates (or static polymorphism) would help. Currently,
> the static polymorphism design is at least one of the causes
> for large compile times (and, I would also guess,
> hard-to-read compiler error messages).
> 
> IIRC (in one of Joel's ancient posts?), the the predecessor
> to spirit did use dynamic polymorphism, and, again IIRC, it
> was switched to static polymorphism to speed the run-time.
> However, the speed-up in run-time came at the cost of
> slow-down at compile time.
> 
> What I'm proposing is analogous to current compilers
> supplying an optimization flag. For example, -O0 means no
> optimization (analogous to the proposed spirit dynamic
> polymorphism) and -O3 means strong optimization (analogous
> to the proposed spirit static polymorphism == the current
> spirit).
> 
> Spirit users would develop their grammars using the dynamic
> spirit, and once it was debugged, they could switch to the
> static spirit. I would guess that the dynamic spirit could
> would have virtual functions to generate the code for the
> static spirit. This is analogous to bison taking a parse.yxx
> file and parse.tab.cxx.
> 
> Of course there is the small matter of the, I would guess,
> somewhat large development effort in such a redesign ;)
> Whether that development effort is worth the saving in
> compile time's and development times of future spirit users
> is an open question, but worth consideration.
> 
> -regards,
> Larry

at least speaking for me I do rarely apply changes to my grammar that affect
every rule I defined. Instead only a few rules are adapted. If this is the case
for you all as well, did you consider splitting the parser into multiple headers
and/or compilation units?

By doing so one can further reduce the amount of code being recompiled during
each development iteration. Especially for new low level grammar rules there are
usually only few dependencies on other rules which makes them very cheap to test
using an iterative, test driven approach. As soon as the testing is finished,
there is no need to recompile them again and one can proceed with higher level
rules that build upon the lower level ones.

The macros `BOOST_SPIRIT_DECLARE`, `BOOST_SPIRIT_DEFINE` and
`BOOST_SPIRIT_INSTANTIATE` also allow you to maintain both a header-only and a
precompiled library of the parser's rules at the same time using explicit
template instantiation.

Do you think this might help?

As I am posting the first time here I also would like to take the opportunity to
thank Agustín Bergé and Jeroen Habraken for their extensive support on the
freenode IRC channel in the time when I implemented my first parser using X3.
Without them it would have taken a lot longer to understand all the concepts.
And altough everything seems so easy and elegant now, it was quite some work to
get it right ;-) Thank you!

Best regards
Christoph

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Spirit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-general