Greetings to the pub ;)
I will have to have a look at recent releases of Qi4j. In my tests the loading
speed is nowhere near 10k Entities/s. So I assume something has significantly
changed after 1.0 in this regard.
And, do you think the cache could be used to share Entity instances between
UoWs? This could perfectly solve the RAM *and* load time issues I'm facing.
Anyway, I will check the caching API.
Thanks.
-Falko
Niclas Hedhman schrieb:
At pub, so don't assume I got all this right; In version 1.3(?) we
abstracted the caching into Extensions. However, IIRC it doesn't deal with
the UoW isolation that is needed.
WAY back (0.1?), we had a read-only cache 'under' the UoW to support these
kind of issues. Can't recall why it became a problem?
On Dec 14, 2011 6:26 PM, "Falko Bräutigam" <[email protected]> wrote:
Hi all,
thinking a bit more about the "Performance and RAM consumtion" EMail. It
seems that the value cache the PropertyInstance is/has (except for
Collection values) is related. I see 2 functions of this value cache:
1. cache deserialized values and make access fast
2. allow to modify an Entity without modifying the underlying store
The problem is that this caching behaviour is hardwired and cannot be
switched of. If I got him right this is related to Niclas idea of a
read-only UoW. If 2. would be done somewhere else, then the cache could be
switched off or even better factored out to be a concern that could have
different implementations.
If the Property value cache could be factored out of the PropertyInstance
implementations, then is would allow for:
* plugable implementations
* no cache at all
* per Property caching (instead of per Entity)
* sharing of values across Entities
The last one is half the way to a copy-on-write implementation (that is
able to copy *just* the modified properties instead of the entire entity).
Does that make any sense? Any ideas?
-Falko
--
Falko Bräutigam
http://polymap.org/polymap3
______________________________**_________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/**mailman/listinfo/qi4j-dev<http://lists.ops4j.org/mailman/listinfo/qi4j-dev>
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
--
Falko Bräutigam
http://polymap.org/polymap3
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
