Part of the problem with Elephant is that we currently create CLOS
objects in memory for every 'row' that is touched in a query (or
touched during an index operation). We have to de-serialize the
record, create an object, initialize any transient slots, etc. The
SQL engine, by contrast, can just keep track of a list of OIDs and
then count the size of the arrays that result from any joins. This is
a much cheaper set of operations per-row (i.e. per object). If we
only read OIDs into memory until the final step when we need to access
a slot, we can save quite a bit of the cost of object creation.
My hope is that a query system would implement this model properly.
Unfortunately, this will not happen soon, as much as I'm itching to do
it!
However, the recent change to split object instantiation into initial
and deserialization pathways should have sped things up a bit (e.g. no
p-slot accesses during de-serialization).
Ian
On Jan 20, 2008, at 9:32 PM, Joubert Nel wrote:
Hello,
I did some reading through the mailing list archives and the Elephant
manual, but cannot find a recommended way of counting the number of
persistent objects of a particular class.
I have a method that works (using map-class) but this is way too slow
for my purposes.
I did find some postings from Oct last year about this question but no
definitive answer it seams.
Any advice?
Joubert
PS: I'm using the postmodern back-end.
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
