[elephant-devel] Optimization

[Elliott Slaughter]

Hi,

On Mon, Dec 29, 2008 at 2:46 PM, Ian Eslick <eslick at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20090108/c4cfdc0d/attachment.html>