On 2010-10-20, [email protected] <[email protected]> wrote: > ============================================================================= > Today's Topic Summary > ============================================================================= > > Group: [email protected] > Url: http://groups.google.com/group/topbraid-users/topics > > - Inference 40x faster after TBC restart and save model [2 Updates] > http://groups.google.com/group/topbraid-users/t/c5abfc9e0eee6a6b > - cache for Oracle hierarchies in Live [1 Update] > http://groups.google.com/group/topbraid-users/t/d4ce496f436354e0 > > > ============================================================================= > Topic: Inference 40x faster after TBC restart and save model > Url: http://groups.google.com/group/topbraid-users/t/c5abfc9e0eee6a6b > ============================================================================= > > ---------- 1 of 2 ---------- > From: Arthur Keen <[email protected]> > Date: Oct 19 11:13AM -0500 > Url: http://groups.google.com/group/topbraid-users/msg/973185ba0afe518f > > Scott, > > It is repeatable. It happened on Friday last week, and I spent yesterday > confirming it, before raising the issue with you guys, because it seemed too > good to be true. I did not try it on the 10 and 100 family, since the 1000 > family model was already hitting 1 second response time. I was expecting an > answer like you have to "re-index", or "re-balance", or "optimize" since a > large number of new triples got added or there is something wrong with the > way you are creating instances. While demonstrating this to a colleague > yesterday, I took the saved 1000 family model and added 100 more families to > make 1100 and the inference speed slowed down dramatically. Also the reset > on the unsaved models is also orders of magnitude slower than on the > saved/restarted models. > > Unfortunately, the test models are on a secure network, else I would send > you a copy. It is a very simple model, so I will reconstruct it and send it > to you later today. > > FYI, It consists of the following models: > schema.n3 Defines Person, Man, Woman, hasChild, hasFather, hasMother, > hasSon, hasDaughter > rulesspin.n3 Imports schema.n3 and defines SPIN rules for > inferring hasFather, hasMother, hasSon, hasDaughter from hasChild > rulesjena.n3 Imports schema.n3 and defines jena rules for > inferring hasFather, hasMother, hasSon, hasDaughter from hasChild > rulesswrl.n3 Imports schema.n3 and defines swrl rules for > inferring hasFather, hasMother, hasSon, hasDaughter from hasChild > instances.n3 Imports schema.n3 and defines a SPARQL CONSTRUCT query for > generating families consisting of 2 parents (Man/Woman) and 2 children > (Man/Woman) using hasChild > instancesspin.n3 Imports instances and rulesspin.n3 > instancesjenarules.n3 Imports instances and rulesjena.n3 > instancesswrlrules.n3 Imports instances and rulesswrl.n3 > > Test procedure > 1) I set the iterator to 1000 on the query in instances.n3 > 2) Run the SPARQL construct query in instances.n3 for 1000 families, > 3) Assert the inferred triples > 4) Run inferences on instancesspin.n3, record time, hit reset, (avg 3 runs = > 38 seconds) > 5) Run inferences on instancesjenarules.n3, record time, hit reset, (avg 3 > runs =41.667 seconds) > 6) Run inferences on instancesswrl.n3, record time, hit reset, (avg 3 runs > =41.667 seconds) > 7) Save instances.n3 and restart TBC and repeat 4) 5) 6) inference time 1 > second. > > Also simply saving instances.n3 and closing and re-opening it has no effect > on performance, probably because it stays in memory because of the imports. > I have not tried closing and re-opening all of the models. I think the > latter may have the same effect as restarting tbc. > > On Mon, Oct 18, 2010 at 11:02 PM, Scott Henninger < > > > ---------- 2 of 2 ---------- > From: Scott Henninger <[email protected]> > Date: Oct 19 11:02AM -0700 > Url: http://groups.google.com/group/topbraid-users/msg/330a5deae970e8a3 > > Arthur; Yes, having the model and scripts will help us understand the > issue better. > > -- Scott > > > > > ============================================================================= > Topic: cache for Oracle hierarchies in Live > Url: http://groups.google.com/group/topbraid-users/t/d4ce496f436354e0 > ============================================================================= > > ---------- 1 of 1 ---------- > From: Catrina <[email protected]> > Date: Oct 19 06:46AM -0700 > Url: http://groups.google.com/group/topbraid-users/msg/7e7db53102d097fd > > Is there a way to refresh the cache in TBLive programmatically? > Possibly throught a SPARQLMotion script? We are currently using the > cacheAll configuration in Live. > > Thanks, > Catrina > > > > > -- > You received this message because you are subscribed to the Google > Group "TopBraid Suite Users", the topics of which include TopBraid Composer, > TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. > To post to this group, send email to > [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/topbraid-users?hl=en >
-- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en
