Caching in the dynamic database

Michael Ben Yosef <[email protected]>
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <CABnaNcq5OzP8e+MaYq0UdP-jDmKRVEBqHqoU-nO0uwCKwautOQ@mail.gmail.com>
Hi everyone,

As we know, with library(persistency) one can persist (a chosen subset
of) the dynamic database. It would also be nice to be able to
implement caching when the total data grows larger than main memory,
so that, for example, least recently used persistent clauses could be
retracted to make way for new ones to be asserted.

Is there any reason (e.g. JITI or dynamic database garbage collection
characteristics) why it would be infeasible to frequently retract
disk-persisted facts when they are not needed and re-assert them from
disk when the are needed again?

What is the best way to estimate the current size of the dynamic
database in memory for this purpose, i.e. so that caching policies can
be based on how full memory is? It seems one should be able to do this
with statistics/2, but I'm not sure which statistic to use. My
installation gives

?- statistics(heapused, X).
X = 0.

i.e. heap used is not maintained - is there a compile-time option I
should enable so that the system keeps track of it? I also get

?- statistics(memory, [Total, Free]).
Total = 23768,
Free = -23769.

and I'm not sure if that's correct, nor how to interpret it if it is.
Under "codes" the table says

"Total size of (virtual) executable code in words"

I take it that that's VM words, not the number of *machine* words
occupied by stored clauses, else it should be expressed in bytes as
the table title suggests. Or could this somehow be used to estimate
space usage?

Thanks in advance!

Michael
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.