Slow on stable/7.2.3, fast on devel/7.3.24/29

18 views
Skip to first unread message

Jacek

unread,
Nov 8, 2016, 10:09:18 AM11/8/16
to swi-p...@googlegroups.com
  Hello,

It's my first post at this forum, so before I start I'm sending big THANK YOU to the developers and maintainers of the SWI-Prolog. It's fantastic work!

Now my issue... I've been trying to implement a web service using Prolog (SWI-Prolog) and found a strange performance problem.
My service collects and stores user-provided facts (by means of the persistency module) which then I wanted to query to get some useful information.
At the moment my database has grown to a little more than 110MB/420k clauses.

My trouble is that running it on the latests stable version -- 7.2.3 -- makes even basic queries running very slow. Without going into too many details, a simple query in the interpreter can take anything from 3–8 seconds per single response. Then, running findall(...) to collect all responses (70 elements) took my VM about 28 minutes!

Luckily, I've tried running the same database and queries on SWI development releases 7.3.24 and 7.3.29. In that case, querying a single response is instantaneous, likewise the findall(...) which took only 0.051 seconds to return the list.

I'm curious from where such significant difference can come? But more importantly, is there anything in particular I should be cautious about when using the development version? Unfortunately, using the stable release undermines the whole concept of using Prolog as an implementation platform, yet I'm happy to use the development release unless it's safe.

If all above sounds too cryptic, I'm happy to share more details about the database and queries to help answer my questions.

  With best regards,
  Jacek

Jan Wielemaker

unread,
Nov 8, 2016, 10:25:11 AM11/8/16
to Jacek, SWI-Prolog
On 08/11/16 16:09, Jacek wrote:
> Hello,
>
> It's my first post at this forum, so before I start I'm sending big
> THANK YOU to the developers and maintainers of the SWI-Prolog. It's
> fantastic work!
>
> Now my issue... I've been trying to implement a web service using Prolog
> (SWI-Prolog) and found a strange performance problem.
> My service collects and stores user-provided facts (by means of the
> persistency module) which then I wanted to query to get some useful
> information.
> At the moment my database has grown to a little more than 110MB/420k
> clauses.
>
> My trouble is that running it on the latests stable version -- 7.2.3 --
> makes even basic queries running very slow. Without going into too many
> details, a simple query in the interpreter can take anything from *3–8*
> seconds per single response. Then, running findall(...) to collect all
> responses (70 elements) took my VM about *28* minutes!
>
> Luckily, I've tried running the same database and queries on SWI
> development releases 7.3.24 and 7.3.29. In that case, querying a single
> response is instantaneous, likewise the findall(...) which took only
> *0.051* seconds to return the list.

Looks like an indexing issue. Arbitrary argument JIT is present in both
versions, but only recent 7.3.x versions index on strings and floats.
Older versions only on atoms, integers and the principle functor of
compound terms. If you tell us the argument types of your clauses and
which query you run it might be possible to tell more.

> I'm curious from where such significant difference can come? But more
> importantly, is there anything in particular I should be cautious about
> when using the development version? Unfortunately, using the stable
> release undermines the whole concept of using Prolog as an
> implementation platform, yet I'm happy to use the development release
> unless it's unsafe.

The development version is very stable at the moment. Much more so
than the stable version. Check recent posts (last couple of weeks)
for the discussion.

Cheers --- Jan

Jacek

unread,
Nov 8, 2016, 10:37:44 AM11/8/16
to SWI-Prolog, jacek...@gmail.com
Thank you Jan!

That's it: my clauses use strings heavily, so happy to hear your answer. Switching to the latest devel, then.

  Best regards,
  Jacek
Reply all
Reply to author
Forward
0 new messages