🚀 go-pugleaf

In article <607@ecrcvax.UUCP>, micha@ecrcvax.UUCP (Micha Meier) writes:
> In article <184@quintus.UUCP> ok@quintus () writes:
> >A fast compiler is well worth having, but I think it is better for Prolog
> >users in the long run if vendors try to make faster compilers *in Prolog*.

> I've seen quite a few Prolog compilers in Prolog, and all of them
> are really *slow* compared to the C version. I suggest that
> people analyze their Prolog compilers and share the experiences,

In SB-Prolog, much of the compilation time is accounted for by the front
end: the parser, which is written in Prolog, builds a term from a list of
tokens; this term is then transformed to an annotated syntax tree.  This --
especially the transformation to the annotated syntax tree -- seems to
account for a large fraction of the total compilation time.  (The
less-than-optimal symbol table management strategy doesn't help.)

The lack of destructive assignment also undoubtedly affects compilation
speed: e.g., during peephole optimization, the instruction stream is copied
repeatedly instead of being modified in place.  However, my feeling is
that the effect of this isn't as bad as one might expect, and can be reduced
substantially with proper choice of data structures (sorry, no numbers).
-- 
Saumya Debray		CS Department, University of Arizona, Tucson

     internet:   debray@arizona.edu
     uucp:       arizona!debray