From a-doug@microsoft.com  Fri Jan  7 17:13:33 2000
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by swi.psy.uva.nl (8.9.3/8.9.3) with SMTP id RAA15775
	for <prolog@swi.psy.uva.nl>; Fri, 7 Jan 2000 17:13:32 +0100 (MET)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Jan 2000 08:10:19 -0800 (Pacific Standard Time)
Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21)
	id <C37TMK03>; Fri, 7 Jan 2000 08:10:18 -0800
Message-ID: <E713F2760348D211A9B600805F6FA1AB0355990B@RED-MSG-09.itg-messaging.redmond.corp.microsoft.com>
From: "Douglas Miles (Volt Computer)" <a-doug@microsoft.com>
To: "'Jan Wielemaker'" <jan@swi.psy.uva.nl>,
        "'liraola@opera.dia.fi.upm.es'"
	 <liraola@opera.dia.fi.upm.es>
Cc: "'prolog@swi.psy.uva.nl'" <prolog@swi.psy.uva.nl>
Subject: RE: Performance degradation revisited (SWI-Prolog 3.3.0 beta-9)
Date: Fri, 7 Jan 2000 08:10:10 -0800 
X-Mailer: Internet Mail Service (5.5.2650.21)

Ah, yes mine was with Wordnet 1.6 as well..

First in 2.2.7/8
And I had compared the consult times between atoms and lists_of_ascii
in.. 
s(100001740,1,'entity',n,1,1).
s(100001740,2,'something',n,1,0).
vs.
s(100001740,1,"entity",n,1,1).
s(100001740,2,"something",n,1,0).
The result was the Atom version consulted much quicker then the char_lists

So I adopted Atomic method

now in 3.3.0
I had continued using the Atom method..
We should check if we need to go back to the char_list method.
Since we are creating at least 174,008 Atoms <lol>
We (Luis and I) probably both fell into the same boat.
But hrrm what shall we do?
Reason tells me char_list in that we are actually going to use it against
ASCII input.

on a side note..
I recreated the WordNet 1.6 in some better prolog formats more compatible
with "usability"
as
like hyp/4 and nt/4 and all those Thing/4 got moved to tt/3
tt(hyp, 100002880, 100002086).
tt(hyp, 100003011, 100002086).
tt(ant, 100010123, 100011937). /* we look at meanings not grammar */
tt(ant, 100011937, 100010123).
it available.. http://wordnet.prolog.magick.nu/library/wn_tt.non_btree.pl

also ..Unless if you really are using the extra info in s/6 
s/6 got converted to.. 
5 separate VERY LARGE files for reasons that actually improved WorldNet's
performance!
http://wordnet.prolog.magick.nu/library/nouns.pl (w_n/2)
http://wordnet.prolog.magick.nu/library/verbs.pl (w_v/2)
http://wordnet.prolog.magick.nu/library/adverbs.pl (w_av/2)
http://wordnet.prolog.magick.nu/library/adjectives.pl (w_a/2)
http://wordnet.prolog.magick.nu/library/adj_sat.pl (w_as/2)

then look at the bottom of 
http://wordnet.prolog.magick.nu/library/tokenization.pl 
to see how I reunify these into what we need

I am going to convert those 5 files from Atoms to char_lists if Jan thinks
its a good idea

Thank you,
	Douglas Miles a-doug@microsoft.com
	<goofy-ms.gif> 


-----Original Message-----
From: Jan Wielemaker [mailto:jan@swi.psy.uva.nl]
Sent: Friday, January 07, 2000 6:10 AM
To: Luis Iraola Moreno; Luis Iraola Moreno; prolog@swi.psy.uva.nl
Subject: Re: Performance degradation revisited (SWI-Prolog 3.3.0 beta-9)


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


----------------
* To UNSUBSCRIBE, please use the HTML form at

    http://www.swi.psy.uva.nl/projects/SWI-Prolog/index.html#mailinglist

or send mail to prolog-request@swi.psy.uva.nl using the Subject:
"unsubscribe"
(without the quotes) and *no* message body.

** An ARCHIVE of this list is maintained at

    http://www.swi.psy.uva.nl/projects/SWI-Prolog/mailinglist/archive/

