On 2009-10-16 15.59, Niclas Hedhman wrote:
IIRC, they are (or can be) established "per session".
Ok, that's a start then. Still too coarsegrained, really.
What would be interesting is to have the store work on two levels: one is
the identity lookup, and then the next level would be property(/association)
lookup. If one index can have only identity lookup and another has the
per-property lookup, it should be much faster.
Not totally sure what you mean here. Two-level index?
Simply having one index for id->entity and another for
entity->property/association. Right now the second level is implicitly
done in the JSON, which has key=value data. But if that could be done
without having to *read* all of the data, it would be more efficient.
I think we need to measure before having any conclusive opinion on
what makes sense or not. But such performance testing is tedious and
perhaps the "Delayed Property creation" is a reasonable first step,
before we have effort available to do more elaborate things.
Agree.
Well, for local stores there is the O/S that will pre-load buffers and
stuff like that, so for benchmarking it may show that big blobs
doesn't make a difference, because the O/S will manage to keep 500MB
of data in OS-level caches. Such thing would not happen in network
based ones, but there we have latency vs bandwidth to consider as
well. But, it could be anything...
Yeah, that sounds very reasonable. So, just doing the
lazy-property-instantiation should give us some headstart.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
