Re: [eclipse-clp-users] Is referenced_record/2 related to accessing asserted clauses?

Hi Edwin,

I think the main point here is -- as Thorsten said -- dynamic clauses is 
not the best way in ECLiPSe to do what you want.

On 23/11/2012 08:31, Edwin Wirawan wrote:

> I tried profiling a run of my code and the result showed that the majority of the time (~80%) is spent in referenced_record/2.
>
> My code asserts a lot of dynamic clauses at runtime and refers to these dynamic clauses regularly.
>
> Does referenced_record/2 spend most of its runtime accessing asserted clauses, or doing something else?

I assume you are running ECLiPSe 6.0 (or newer). The way dynamic 
predicates are implemented was changed in that version, and it is now 
implemented using the recorded database (record/2 and friends), and 
referenced_record/2 is likely used to access the asserted clauses as you 
suspect.

>
> FYI, each asserted clause is of the form: edge(edgeN,
> ...more content...), where edgeN is unique for each asserted edge clause (e.g., edge1, edge2,edge3,…).
>
> ~200K such clauses are asserted during a typical run.
>

It looks like your clauses are basically data, and as Thorsten said, it 
is not efficient to uss dynamic clauses for this. The user manual has a 
chapter on non-logical storage that discuss the various ways you can 
store and access data non-logically.

A slight correction to Thorsten's comments -- dynamic clauses are 
"indexed" to some extent, i.e. there is some filtering of clauses that 
have the same name and arity, because recorded/2, which is used to 
access the clause, does do some filtering, but as Thorsten shows, it is 
not that effective when you have a large number of clauses.


> A slightly related question: I also called statistics/1. There were
> 200K+ dictionary_entries, dict_hash_usage showed that the dictionary was
>   full (8192/8192) and the dict_has_collisions had a value of
> (196801/8192).
>
>
> My guess is that the majority of 200K+ dictionary entries correspond to
>   our asserted 'edge' clauses, which leads me to wonder if the large
> number of dictionary collisions means that the dictionary is using the
> functor 'edge' or some other conflicted
>   value as a key instead of my unique edge ID values. Does that seem
> right? Would the dictionary hash function have any difficulty
> distinguishing IDs that share a common substring such as 'edge', and
> thus cause the seemingly high number of collisions?

I am guessing that your 'edge' id are implemented as atoms (as opposed 
to strings), as I don't think strings goes into the dictionary (and are 
not indexed, so using strings as unique ids is a bad idea).

I suspect if you have so many different ids, you may be better off using 
integers (I assume you generate your 'edge' ids by combining an integer 
with the atom edge anyway), as integers do not need to be added to the 
dictionary, and I suspect they might index better than the atoms as well.

>
> I am also wondering whether there is a way to inspect the structure and
> content of the dictionary and the database of asserted clauses, and also
>   whether there's a memory profiler for ECLiPSe.

I don't think there is anyway for a user to examine the dictionary. For 
asserted clauses, you can using listing/1 to list the clauses, but this 
would not give you any information on how well the filtering works.

Cheers,

Kish