Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!mcvax!enea!ttds!draken!sics!lhe
From: lhe@sics.se (Lars-Henrik Eriksson)
Newsgroups: comp.lang.prolog
Subject: Re: Standard of Prolog code
Message-ID: <1528@sics.se>
Date: Mon, 5-Oct-87 06:41:33 EDT
Article-I.D.: sics.1528
Posted: Mon Oct  5 06:41:33 1987
Date-Received: Sat, 10-Oct-87 18:31:13 EDT
References: <2265@mulga.oz> <5005@utah-cs.UUCP> <2217@megaron.arizona.edu>
Reply-To: lhe@sics.se (Lars-Henrik Eriksson)
Organization: Swedish Institute of Computer Science, Kista
Lines: 31

In article <2217@megaron.arizona.edu> debray@arizona.edu (Saumya Debray) writes:
>Talking about implementations, I was quite surprised to see, at SLP 87
>earlier this month, at least two high-powered commercial Prolog systems
>suffer a factor of 3 slowdown when I changed append/3 from
>
>	append([],L,L).
>	append([H|L1], L2, [H|L3]) :- append(L1, L2, L3).
>to
>	append([],L,L).
>	append([H|L1], L2, L) :- L = [H|L3], append(L1, L2, L3).
>
>Their performance, on naive reverse on a Sun-3/75, dropped from about
>140 KLIPS for the "usual" append to about 40 KLIPS for my "mutant"
>append.  You think people would do a better job of handling 
>inline predicates and temporaries!

In at least one "high-powered commercial Prolog system" naive reverse
suffers a 35% slowdown (on a SUN) when you change append/3 to

	append([],L,L).
	append([H|L1], [H|L2], L3) :- append(L1, L2, L3).

i.e. change the order of the second and third arguments! The slowdown of append
itself is obviously greater, although I haven't made any measurements.
Apparently poor handling of inline predicates isn't the only thing that's
going on...

Lars-Henrik Eriksson					lhe@sics.se
Swedish Institute for Computer Science
Box 1263
S-163 13  SPANGA, SWEDEN