Hi, On Mon, Dec 29, 2008 at 2:46 PM, Ian Eslick <esl...@media.mit.edu> wrote:
> > I checked the cache-checkout model to elephant-unstable. > Thanks for your work on slot caching. I've been playing around with checkout caching for the last week or so, and a couple of comments and critiques. - On checkout, the cached slots of the checked-out object behaves > like a standard built-in object, although with MOP overhead on > accesses (see below) > - Write operations are also cached > - The persistent-checkin operation write the current cached slot state > to the DB > - You can sync a currently checked out object to make its state > persistent > - Checkout can be cancelled > The checkout model seems just a little awkward to integrate with my code. Since I am usually working with what is effectively a tree of objects, I typically want to checkout an entire subtree at any given time. I already have code which walks over the tree, but since the tree is heterogeneous, and may not necessarily consist of just cacheable objects, a simple call to persistent-checkout for each object won't do. The following works, but is a hack based on the internals of cached-slots.lisp: (when (eq (ele::%cache-style (class-of object)) :checkout) (ele:persistent-checkout object)) Also, there are times when I would like to instantiate and immediately checkout an object. However, I am experiencing a strange bug where adding an after method to initialize-instance results in a slot-unbound error later if make-instance is called from inside with-transaction. Unfortunately, I haven't been able to reproduce the bug in any self-contained test case (and I can't say for sure that it isn't my error). Another issue is that the cache-style declaration in persistent classes doesn't get inherited by default. This particularly annoying since this throws an error merely by inheriting cached slots from a superclass. Finally, I believe (if I understand indexing correctly) that caching write operations makes it impossible to have indexed cached slots. My most expensive slot reads (after optimizing all other persistent slots) come from indexed slots. That said, I could probably avoid reading indexed slots if I used the query language discussed on another thread. (Currently I use get-instances-by-value to cons a list of objects, and then sort by the indexed slot to effectively iterate over two sorted slots.) Standard: 25M/sec > Cached: 7M/sec > Persistent (within a transaction): 140k/sec > > Cached slot access is now only 4x slower than standard slot access > Persistent slot access is about 50x slower than cached slot access I get roughly the same results as you on the micro-benchmarks. When using checkout caching in the game, I get about a 2x speed increase. It is still about 3x slower than no database. Thanks again. -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert
_______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
