[mercury-users] compilation time

Thomas Conway conway at cs.mu.OZ.AU
Tue Feb 22 08:26:11 AEDT 2000

On Tue, Feb 22, 2000 at 06:09:32AM EST, Robert Bossy wrote:
> Hello,
> I came to compile a thousand lines long mercury code and it took nearly
> 5 minutes.

Count yourself lucky. Yesterday I found a performance bug in the compiler
and my 70 line module took 2 hours to compile. Fortunately it looks like
Fergus has found and fixed the problem, so it should go back to taking
the few seconds it should.

Generally speaking though, if you have large tables of facts, or large
constant terms, these are both things which can trigger super-linear
running times. With facts, you can sometimes break them up which helps.
For example in my clone of yacc: moose, I generate the parsing tables
as facts:

:- pred action(state, symbol, action).
:- mode action(in, in, out) is semidet.

action(state1, id(_), shift(state2)).
action(state1, (+), shift(state9)).
.... for a thousand or more lines ....

The compile time for this sort of thing is very big.
You can get a very substantial improvement by breaking
it up:

action(state1, Sym, Action) :-
	actions1(Sym, Action).
action(state2, Sym, Action) :-
	actions2(Sym, Action).

:- pred actions1(symbol, action).
:- mode actions1(in, out) is semidet

With large constant terms there are a couple of things you can try.
Read them in at runtime or compute them at runtime if they're
medium sized. Another option is to split them into smaller
constants (in separate predicates) and assemble the pieces at

Hope this helps,
 Thomas Conway )O+     Every sword has two edges.
     Mercurian            <conway at cs.mu.oz.au>
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe

More information about the users mailing list