[elephant-devel] Optimization

[Ian Eslick]

By the way, a write through mode is complex because if a transaction  
is rolled back your index could differ from your memory state so you  
would then have to keep track if slot writes to undo them on rollback...

Are you caching blocks of objects for short term operations or long  
term ones?

Sent from my iPhone

On Jan 8, 2009, at 7:38 AM, Ian Eslick <eslick at media.mit.edu> wrote:

> Great feedback!  Thank you.  It's always great to have different use
> cases.
>
> Comments below.
>
> On Jan 8, 2009, at 3:22 AM, Elliott Slaughter wrote:
>
>> 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))
>
> We could provide an optional argument to checkout that silently
> succeeds.
>
>> 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).
>
> I'll do a quick code review tonight and see if something is obvious.
>
>> 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.
>
> Hmmmm...it should inherit by default unless you are overriding the
> base class slot.  I'll look into this too.
>
>> 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 is correct.  We could make a 'write-through' mode, but then we'd
> need 'cached-index' slots as a special case and I'm trying to avoid a
> combinatorial explosion in slot types.
>
>> 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.)
>
> The query system would basically do this:
>
> (let ((a (map-inverted-index #'identity 'slot1 :collect t :oids t))
>       (b (map-inverted-index #'identity 'slot2 :collect t :oids t)))
>   (mapcar #'elephant::controller-recreate-instance
>         (merge-unique (sort a #'<) (sort b #'<))
>
> I need to export recreate...
>
> You can also do map-inverted-index and accumulate only values matching
> the second value as discussed earlier using an accumulation closure as
> an argument.  For small sets on the first slot, this is probably
> faster.  In general mapping is always more efficient than get-
> instances...
>
>
>> 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.
>
> It would be interesting to see some profile data on this to see what,
> if anything, in BDB/Elephant could be improved.
>
>> Thanks again.
>>
>> -- 
>> Elliott Slaughter
>>
>> "Any road followed precisely to its end leads precisely nowhere." -
>> Frank Herbert
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel