On 28/11/2012 05:01, Edwin Wirawan wrote: > Hi Kish, Thorsten, > > While using a store is much faster than using dynamic clauses when we only need to access a single > item, the performance seems similar when we need to access every single item in the store / > asserted database. > My code needs to do the latter, i.e. it needs to visit every item whenever it is accessing the > database, so replacing the asserted database with a store would not seem to provide a lot of speed-up. > > It seems that in order to tap into the store's superior performance, I would have to use the store > in a way such that the key of the store is not merely an edge ID, which doesn't allow the code to > constrain the search > through the items in the store, but rather a key that reflects some constraints that would narrow > down the search to a subset of all the items in the store. > > Is there an alternative which would not involve constraining the search and therefore would still > access every single item in the store / database, while still providing a considerable speed-up? If you store your graph data in clauses or a "store" (which are both persistent with respect to backtracking), then every access involves a relatively expensive copy operation. You should therefore consider representing your graph as a normal data structure, which gets passed around as an argument to your predicates. A suitable graph data structure is defined in library(graph_algorithms), which also gives you a number of useful operations on such graphs. There is also some visualization support for these graphs. http://www.eclipseclp.org/doc/bips/lib/graph_algorithms/index.html http://www.eclipseclp.org/doc/bips/lib/graphviz/index.html -- JoachimReceived on Tue Dec 04 2012 - 17:04:58 CET
This archive was generated by hypermail 2.3.0 : Wed Sep 25 2024 - 15:13:20 CEST