# Listing/1 works slowly in specific circrumstances

**URL:** <https://swi-prolog.discourse.group/t/listing-1-works-slowly-in-specific-circrumstances/9780>\
**Category:** General\
**Created:** [August 5, 2026, 2:28pm UTC](https://swi-prolog.discourse.group/t/listing-1-works-slowly-in-specific-circrumstances/9780 "2026-08-05T14:28:23Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![AlexeyKosarchuk](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/alexeykosarchuk/32/4466_2.png) [@AlexeyKosarchuk](https://swi-prolog.discourse.group/u/AlexeyKosarchuk)\
**Post date:** [August 5, 2026, 2:28pm UTC](https://swi-prolog.discourse.group/t/listing-1-works-slowly-in-specific-circrumstances/9780/1 "2026-08-05T14:28:23Z")

</div>

I have strange situation using SWI Prolog listing/1 predicate.  
I have several dynamic predicates used as database for some state.

Initially state is constructed from scratch by some program. Then I can save it to file by calling listing/1 predicate and redirecting output to file. To load state I just consult this file on clean state and everything works fine except for one specific scenario:

If I save state that was constructed from scratch, listing works fast.  
If I try to save state, that was previously restored, listing works very slow - like taking 2 minutes to dump 5000 clauses.

I have no idea what can it be and how to fix it (((

---

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [August 5, 2026, 2:59pm UTC](https://swi-prolog.discourse.group/t/listing-1-works-slowly-in-specific-circrumstances/9780/2 "2026-08-05T14:59:34Z")

</div>

> [@AlexeyKosarchuk](#):
>
> I have no idea what can it be and how to fix it (((

Neither have I ☹ If you can provide us with something we can run to see what is going on we might be able to find out what happens. If that is hard, the first thing to try is using profile/1 on both the initial save and the slow save and see what has changed.

One option that comes to mind while writing the above is that, when listing from asserted facts, it just lists the database. When listing from loaded source it tries to re-establish the variable names. You can use

```
?- listing(Pred, [variable_names(generated)]).

```

See listing/2.

If you want speed though, use write\_term/3 or write\_canonical/2. listing/0-2 is intended to generate pretty human readable output.

---

<div class="post-metadata">

**Author:** ![AlexeyKosarchuk](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/alexeykosarchuk/32/4466_2.png) [@AlexeyKosarchuk](https://swi-prolog.discourse.group/u/AlexeyKosarchuk)\
**Post date:** [August 5, 2026, 5:58pm UTC](https://swi-prolog.discourse.group/t/listing-1-works-slowly-in-specific-circrumstances/9780/3 "2026-08-05T17:58:46Z")

</div>

I’ve profiled both cases.

In slow case it spends almost all time in skip/2. And a little bit of prolog\_source:seek\_to\_line/2.

My theory is that it is somehow connected to to fact, that when I restore state by consult, predicate has source code file associated with it and it slows later listing call. Initially predicate is constructed via assert calls, and doesn’t have source code associated.

---

<div class="post-metadata">

**Author:** ![AlexeyKosarchuk](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/alexeykosarchuk/32/4466_2.png) [@AlexeyKosarchuk](https://swi-prolog.discourse.group/u/AlexeyKosarchuk)\
**Post date:** [August 5, 2026, 6:11pm UTC](https://swi-prolog.discourse.group/t/listing-1-works-slowly-in-specific-circrumstances/9780/4 "2026-08-05T18:11:49Z")

</div>

Okay, I used listing(…, [source(false)]).

It has improved things a lot - from 42 seconds down to 9.

It is still much more that 0.14 seconds of initial state saving, but is acceptable now.

Again, all 9 seconds are spent in skip/2 somehow.

Thanks for guidance!

P.S. Adding variable\_names(generated) to options has sped it up to 0.05s!

Now even faster than original!

---

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [August 5, 2026, 6:56pm UTC](https://swi-prolog.discourse.group/t/listing-1-works-slowly-in-specific-circrumstances/9780/5 "2026-08-05T18:56:24Z")

</div>

listing/1 and compiling a file are not really meant for this. As said, listing/1 tries to write something human readable and compiling a file does a lot on term expansion, tracking source locations, etc. Consider `library(persistency)` or use clause/2 + write\_term/3 for saving and a loop using read\_term/3 and assertz/1 for loading.

---

<div class="post-metadata">

**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\
**Post date:** [August 6, 2026, 6:42am UTC](https://swi-prolog.discourse.group/t/listing-1-works-slowly-in-specific-circrumstances/9780/6 "2026-08-06T06:42:54Z")

</div>

There’s also library(fastrw), e.g., fast\_read/2, fast\_write/2, fast\_term\_serialized/2.
