The graphical tracer slows to a crawl

Help!
1

I recently installed a new version of Linux, and a new version of SWI-Prolog.
Since doing this, I have seen a problem with the graphical tracer.

The tracer is able to trace through normal rules without problems but when I try to trace through a DCG grammar clause, it slows to a crawl.

grammar_rule(X)   -->
                    [a],
                    grammar_phrase(X),
                    {assert(test(a))}.

When I trace through a clause like this, I can press “s” for “skip”
to make it skip through “grammar_phrase(X)”.
It takes about 20 minutes to skip through it, and reach “assert(test(a))”.
I can then try to skip through “assert(test(a))”.
This is slow too, it takes over a minute to skip through it.

So something has slowed down the tracer.

It appears to be that the tracer goes wrong when I use DCG clauses,
i.e. clauses that use “–>”.

I am seeing this problem in Linux Mint Cinnamon 19.1, with SWI-Prolog version 7.6.4. .
I didn’t see this problem in Linux Mint Mate 18.3, with SWI-Prolog version 7.2.3 .

Do I just need to use a different version of SWI-Prolog, to get graphical tracer that doesn’t have this problem? If so, what version should I get?

Is this bug likely to vanish if I just upgrade to the latest SWI-Prolog, installing from source? Or is it more likely that all versions of SWI-Prolog on Linux Mint Cinnamon have this problem, and I need to use a different distro? Any advice will be welcome.

I also saw this error message at one point.

?- trace, is_etc(A, [is], B).
ERROR: pce(object) `@17528105654451’ does not exist (@17528105654451/prolog_debugger (freed))
A = (is),
B = .

?-

Jan W wrote:

The only problem I know is that the trace Windows and a few other windows of the GUI first show up empty and grey. This problem is related to some window managers, but unfortunately the more popular ones. The window draws if you move it a little or wait long enough.

Yes, I have been getting that problem too.

–
Martin.

2

There is obviously something wrong in that case. But, to say something sensible one needs a complete program and a query to run against it. Of course I can try top to complete it myself, but in my experience I do this differently and the problem vanishes.

3

Solved.

I just spent a lot of time trying to see how to reproduce the tracer speed bug. I have found one line of code in my source code file that makes the graphical tracer slow. The line of code is this.

atom_symbol('/'').

I replaced it with this:

atom_symbol('''').

This works fine.

It wasn’t obvious that this line of code would be relevant, as the code that I was tracing through does not call “atom_symbol”. But when I changed this line, the tracer became fast, as it should be.

–
Martin.

1 Like
4

This is caused by the code trying to find the start of the clause for re-reading it for position details is confused by the '\'' (assuming backslash). AFAIK this has been fixed quite long ago. I’d invest 15 minutes to get installation from source working as most distros are quite slow. On Ubuntu you can activate the PPA to get access to the latest releases as binaries.

5

Most distros are slow? Why would that be?

6

Distros have different policies. (SWI-)Prolog is considered small beer in the distro world. We only have a dedicated maintainer for Debian (Lev Lamberov). Debian has a rather slow and conservative release cycle and is the base of many distros such as Ubuntu, Mint, etc. For more popular systems these derived distros may decide to update faster than Debian, but for (SWI-)Prolog they simply follow.

If people want to change that for their distro, I guess they should contact the community and offer to provide timely updates.

Well, that is my perception of the situation. I may be wrong.

7

I think you mean they are slow to update. I thought you meant the distributed SWI ran slowly.

8

Glad you said that. I was thinking it odd the way it was worded and meant that distros ran slower than other releases. Now it makes more sense.

9

Sorry for the misleading formulation. Surely I assume the builds by distros have practically the same performance as your own build. Two things may be worth mentioning:

  • The script scripts/pgo-compile.sh can be used to build a version with Profile Guided Optimization, which is roughly 7-10% faster. Works fine with GCC. With some help from Paulo it now also works on clang on MacOS, but there it appears to make the system slower rather than faster. Do not ask me why …
  • With the move to CMake/CPack, building your own .deb or .rpm is really easy. That may come handy for installing the latest or a modified version on production Linux machines. See CMAKE.md in the top directory.
10

That might not be true. For a long time, Python in many distros had something like 20-30% worse performance than building with all the proper flags, due to not doing a final pass with FDO. [I haven’t looked at SWI-Prolog’s build to see whether it uses FDO … if it doesn’t, that could be something worth considering]

11

According to Wikipedia, FDO is the same as PGO. See my previous post. Distros probably do not use that. Unfortunately the benchmark suite is really old and fails to benchmark a lot of useful stuff, such as garbage collection, constraint handling, reading, assert/retract, indexing, etc. There is most likely more to gain than the current 7-10%. The code does use GCC annotations to help branch prediction in some time critical and rather obvious places. That should help regardless of FDO/PGO.