[elephant-devel] Optimization

[Alex Mizrahi]

 ES> Are cached slots usable yet (at least in a single-threaded situation)? 
When I use ":cached t" in my slot definitions, I get errors.

i postmodern backend rather than doing caching on a slot level we're doing 
it on btree level. that is, get-value and (setf get-value)
functions do lookups/writes in a cache hash table ((btree-id, key) -> 
value), and this works pretty well, as everything gets
cached. if underlying hash table is weak, it could automatically control its 
size.

the tricky thing, however, is to do it in transaction-safe way. simpliest 
way to do it transaction-safe is to use cache
only within a single transaction, and throw it out afterwards -- then you'll 
never have stale entries. that doesn't work
well of you have lots of small transactions, though. db-postmodern has a 
caching mode where it does additional
changes tracking to invalidate cache entries properly.

but if you know that your application is single-threaded, for example, you 
can do it in easier way -- just keep
using single cache as long as no transactions do rollback, if they do 
rollback you'll have to delete it.

with multiple threads in single process you can handle this via relatively 
easy invalidation protocol, i guess.
(i'm not sure how exactly, though, at moment, as i'm more familiar with MVCC 
concurrency model rather
than bdb's lock based. maybe with lock based model you don't have to do 
much.)

so, what i was going to say, adding caching for your specific application 
can be fairly easy -- you just need
to instrument db-bdb code a little, adding just a few dozen of lines of 
code. so you can just try to do this,
instead of relying on weird slot-caching protocol.