On 20/03/12 06:39, Milorad Tosic wrote:
Andy,
Thanks for sharing the details with us, now it all makes sense. Now I
am able to ask the next question ;-)
What is memory vs. processing cost comparison for different dataset
wrappers (GraphStore, Model, InfModel, etc)?
GraphStore does not add anything except call-throughs to the wrapped
object. JITting might even remove those. In Java terms, it's trivial.
There's a lot more wrapping and conversion of abstraction going on all
the time.
A Model backed by a TDB dataset is again just calling through to the
storage code.
An InfModel is expensive over a database.
In other words, I assume
that one should keep a single dataset instance throughout whole
application since the instance is heavy resource vise. But what about
the wrappers? For example, If I want to work with a GraphStore across
an application, should I create new GraphStore instance over the
single datasource each time I need such a wrapper or should I have a
single GraphStore instance and reuse it across the whole application?
The same question holds for each other type of the datasource wrapper
also (Model, InfModel, ...).
Create GraphStore on each update operation.
With transactions, it's better to create it inside the Transaction and
use only for the transaction. This is more style than performance.
GraphStore wrappers are very cheap.
The rationale for the question is as follows: If memory as well as
processing cost is negligible then instantiation of a wrapper is
voluntary and depends on one's programming style. If memory cost is
high while processing cost is low then the overall cost is reduced to
memory allocation only, and one should optimize according to the
particular system architecture. If memory cost is low while
instantiation processing cost is high then one should have a single
instance that is initialized once and kept in memory during whole
application life time. Since we are dealing with wrappers, the fourth
case, memory as well as processing cost are high, is probably not
possible.
Each abstraction is there for a reason. Worrying about performance
until there is a observable problem can lead to excess development costs.
Andy
Milorad
