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