“We” are the people having this conversation. It’s often very hard for me to understand what you are saying (e.g. “If it makes a difference, it can the implementation for Dataset(Graph)Factory.create()…", so I need to confirm carefully what we are talking about.
If I understand it so far, you want me to execute some TupleTable implementations that use simple datastructures that would not support transactionality but would operate with low overhead so that we can check the performance of a DatasetGraphInMemory using them? --- A. Soroka The University of Virginia Library > On Dec 10, 2015, at 1:07 PM, Andy Seaborne <[email protected]> wrote: > > On 10/12/15 17:41, A. Soroka wrote: >> Ah, okay, cool. But was my other interpretation correct? A >> DatasetGraphInMemory using simple (non-transaction-supporting) TupleTables >> would be good for DatasetGraphFactory::create? >> > > "so we are saying" - who is "we?! > > maybe - if it's appreciably faster, yes; if it's not less point and it adds > to maintenance. > > That's why I was interested in a performance comparison. > >> --- >> A. Soroka >> The University of Virginia Library >> >>> On Dec 10, 2015, at 12:38 PM, Andy Seaborne <[email protected]> wrote: >>> >>> On 10/12/15 17:18, A. Soroka wrote: >>>> Okay, so we are saying that a Dataset around a DatasetGraphInMemory using >>>> simple (non-transaction-supporting) TupleTables would be good for >>>> DatasetFactory::create or ::createGeneral? (Or both— I’m not totally clear >>>> about the difference between them.) >>> >>> General holds graphs from other storages as a ptr to that graph. It is a >>> collection of graphs, no quads. "GRAPH ?g" is a loop. >>> >>> Andy >>> >>>> >>>> --- >>>> A. Soroka >>>> The University of Virginia Library >>>> >>>>> On Dec 10, 2015, at 10:25 AM, Andy Seaborne <[email protected]> wrote: >>>>> >>>>> On 10/12/15 13:31, A. Soroka wrote: >>>>>> To the first question, I think the answer is yes. It was very much my >>>>>> intention that TupleTable and its subtypes would provide opportunity to >>>>>> explore different useful structures (e.g. Claude Warren’s ideas about >>>>>> Bloom filters). A [Triple|Quad]Table that uses ordinary maps/structures >>>>>> in the same way as the current impl uses persistent structures should be >>>>>> very easy. Would you like me to cut such classes to have them available >>>>>> for non-transactional cases? >>>>>> >>>>>> I’m not quite sure what your last sentence means; is it about the >>>>>> semantics of the factory methods? >>>>> >>>>> There are 4 factory methods in each factory >>>>> >>>>> * DatasetFactory.create() >>>>> The new place for in-memory, non-transactional dataset with graph-copy >>>>> semantics. Currently, it is a general dataset with "add graph" >>>>> overridden to do a copy-in. >>>>> >>>>> * DatasetFactory.createTxnMem() >>>>> The new place for in-memory, transactional dataset (with graph-copy >>>>> semantics). >>>>> >>>>> * DatasetFactory.createMem() >>>>> The old place for in-memory datasets - goes to createGeneral() >>>>> Deprecated because if replaced by create() then details have changed. >>>>> >>>>> * DatasetFactory.createGeneral() >>>>> The new place for general datasets. >>>>> >>>>> Andy >>>>> >>>>>> >>>>>> --- >>>>>> A. Soroka >>>>>> The University of Virginia Library >>>>>> >>>>>>> On Dec 10, 2015, at 8:15 AM, Andy Seaborne <[email protected]> wrote: >>>>>>> >>>>>>> On 09/12/15 21:00, A. Soroka wrote: >>>>>>>> Cool. The extension points are basically TripleTable and QuadTable, >>>>>>>> because of the constructor DatasetGraphInMemory(QuadTable, >>>>>>>> TripleTable). Someone could offer their own impls and use that >>>>>>>> (public) constructor. >>>>>>> >>>>>>> Does that mean it would be easy to do a non-transactional version, that >>>>>>> used hash maps (or used hash maps at the top level at least)? >>>>>>> >>>>>>> That would make an excellent performance comparison. >>>>>>> >>>>>>> If it makes a difference, it can the implementation for >>>>>>> Dataset(Graph)Factory.create() and have the copy-in semantics for "add >>>>>>> graph". >>>>>>> >>>>>>> Andy >>>>>> >>>>> >>>> >>> >> >
