But I dont see any utility in investing too much time with the Prolog garbage collection of Dogelog runtime. It is only a small share of the execution time:
Mostowski Collapse schrieb am Freitag, 17. September 2021 um 10:58:57 UTC+2: > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > % Standard Python Version, Warm Run > % ?- time(fibo(23,X)). > % % Wall 3865 ms, gc 94 ms, 71991 lips > % X = 46368. > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > % GraalVM Python Version, Warm Warm Run > % ?- time(fibo(23,X)). > % % Wall 695 ms, gc 14 ms, 400356 lips > % X = 46368. > > The "gc" timing measures Prolog garbage > collection. So you get the following percentage > of time spent in Prolog garbage collection: > > Standard Python: 94 / 3865 = 2.4% > > GraalVM Python: 14 / 695 = 2.0% If you spare these 2-3% it will not speed-up Dogelog runtime. The Prolog garbage collection is there to allow Erlang processes. And its also there to allow more Prolog search without exhausting the memory. But it cost you only 2-3% judging from the Fibonnacci Numbers example. Need to check with other examples whether its higher. But since the ratio between Garbage and non-Garbage is usually high, and non-Garbage is easily identified, and the Garbage is also easily removed, the time will possibly not exceed much more than the same 2-3% for other examples. So in conclusion I am least worried about the Prolog garbage collection. You guys are only worried because its something new. But its nothing that does any harm and costs a lot, it only does good and is very cheap in terms of extra runtime effort. Mostowski Collapse schrieb am Montag, 20. September 2021 um 08:44:49 UTC+2: > This strategy works if you use failure driven loops. > It doesn't work you program recursive loops that go > on forever. Like Erlang processes. > > foo(X) :- > bar(X,Y), foo(Y). > > Typically Y is a fresh variable. A good Prolog system > with good Garbage Collection can run such a process > for days and months. > > If you don't clean up the trail, you exhaust the > memory after a few minutes or seconds. > > Greg Ewing schrieb: > >> On Mon, Sep 20, 2021 at 3:19 AM Mostowski Collapse > >> <janb...@fastmail.fm> wrote: > >>> > >>> On the other hand if I would use the trigger > >>> from Python, I possibly would need a double linked > >>> list, to remove an element. > > > > Here's another idea: Put weak references in the trail, but > > don't bother with the scanning -- just skip over dead ones > > during backtracking. > > > > Seems to me you would be doing about the same amount of > > work either way, just doing it at different times. > > -- https://mail.python.org/mailman/listinfo/python-list