From jan@swi.psy.uva.nl  Fri Jan  7 15:21:05 2000
Received: from gollem.swi.psy.uva.nl (root@gollem [145.18.114.15])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id PAA10963;
	Fri, 7 Jan 2000 15:21:05 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]])
	by gollem.swi.psy.uva.nl (8.9.3/8.9.3) id PAA24927;
	Fri, 7 Jan 2000 15:21:06 +0100
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Organization: SWI, University of Amsterdam
To: Luis Iraola Moreno <liraola@opera.dia.fi.upm.es>,
        Luis Iraola Moreno <liraola@opera.dia.fi.upm.es>,
        prolog@swi.psy.uva.nl
Subject: Re: Performance degradation revisited (SWI-Prolog 3.3.0 beta-9)
Date: Fri, 7 Jan 2000 15:10:00 +0100
X-Mailer: KMail [version 1.0.21]
Content-Type: text/plain
References: <Pine.SOL.3.95.1000107080022.1669A-100000@opera>
MIME-Version: 1.0
Message-Id: <00010715210601.14903@gollem>
Content-Transfer-Encoding: 8bit

Dear Luis

On Fri, 07 Jan 2000, Luis Iraola Moreno wrote:

>I am afraid I have more evidence supporting a serious performance
>degradation in 3.3.0 (beta). I am working with the Prolog distribution of
>WordNet 1.6 and there are major differences between versions 3.2.7 (or
>3.2.8) and 3.3.0 (last beta), all of them running under Windows NT.
>
>Loading the file "wn_s.pl" (about 174.000 facts) with 3.2.7:
>
>19.4 secs. and 19.22 MB.
>
>The same file with 3.3.0:
>
>186 secs and 21.6 MB.
>
>I have repeated the compilation a few times and the results are stable.
>They suggest that the current beta version of the 3.3.0 compiler is
>approximately nine times slower than the previous 3.2.7.

It was even worse on Linux: a 10.9 seconds vs. 135 seconds (Pentium-II
450Mhz, plenty memory).  I found the problem and uploaded the fixed
version as SWI-Prolog 3.3.0-beta9 in the BETA directory (all usual
formats).  With a few other improvements loading performance is very
close to 3.2.8 now.  Most of the problem was caused by a mistake in
the new atom-registration code for the atom garbage collector.

This problem affects any program using lots of atoms.

>Best regards,
>
>Luis Iraola.
>
>P.S.
>Indexing the facts by extra arguments besides the first one (using
>index/1) does not increment the compilation time. On the contrary, it
>seems to speed things up a little bit.

It might yes, as first argument indexing builds a hash-table and other
pattern use a key and key-mask with each clause.  On the other hand,
hashed first argument indexing keeps its performance with large sets
of clauses (the tables are enlarged automatically), while the
pattern-based indexing is still linear to the number of clauses (though
considering a clauses only requires a few statements).

	Regards --- Jan

