<span class="Apple-style-span" style="font-family: 'Times New Roman'; font-size: 16px; "><div style="margin-top: 8px; margin-right: 8px; margin-bottom: 8px; margin-left: 8px; font: normal normal normal small/normal arial; ">
<div class="gmail_quote">Thanks for your comments. Let me try to provide you with a little more information.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, Jan 8, 2009 at 4:38 AM, Ian Eslick <span dir="ltr"><<a href="mailto:eslick@media.mit.edu">eslick@media.mit.edu</a>></span> wrote:<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div><div class="Wj3C7c">On Jan 8, 2009, at 3:22 AM, Elliott Slaughter wrote:</div></div><div class="Ih2E3d"><br></div><div class="Ih2E3d">> Another issue is that the cache-style declaration in persistent<br>> classes doesn't get inherited by default. This particularly annoying<br>
> since this throws an error merely by inheriting cached slots from a<br>> superclass.<br><br></div>Hmmmm...it should inherit by default unless you are overriding the<br>base class slot.  I'll look into this too.</blockquote>
<div><br></div><div>It looks like cache-style is inherited when no new cached slots are declared. But when new cached slots are declared, it produces a rather strange error. I have attached a test case for you to examine.</div>
<div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div class="Ih2E3d">> That said, I could probably avoid reading indexed slots if I used<br>> the query language discussed on another thread. (Currently I use get-<br>> instances-by-value to cons a list of objects, and then sort by the<br>
> indexed slot to effectively iterate over two sorted slots.)<br><br></div>The query system would basically do this:<br><br>(let ((a (map-inverted-index #'identity 'slot1 :collect t :oids t))<br>      (b (map-inverted-index #'identity 'slot2 :collect t :oids t)))<br>
  (mapcar #'elephant::controller-recreate-instance<br>         (merge-unique (sort a #'<) (sort b #'<))</blockquote><div><br></div><div>What I need to do is more like</div><div><br></div><div>(let ((list (map-inverted-index #'identity 'slot1 :value foo :collect t)))<br>
</div><div>  (sort list #'< :key #'slot2))</div><div><br></div><div>which is effectively what I am currently doing with get-instances-by-value. Is there a better way to efficiently iterate over one value in the first slot, with the ordering of the second slot? (Should I look into creating another level of btree for holding each subset of object in order?)</div>
<div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
You can also do map-inverted-index and accumulate only values matching<br>the second value as discussed earlier using an accumulation closure as<br>an argument.  For small sets on the first slot, this is probably<br>faster.  In general mapping is always more efficient than get-<br>
instances...</blockquote><div><br></div><div>Most of the time, the sets will be close in size. Less frequently, the second set will be much larger.</div><div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div class="Ih2E3d">> I get roughly the same results as you on the micro-benchmarks. When<br>> using checkout caching in the game, I get about a 2x speed increase.<br>> It is still about 3x slower than no database.<br>
<br></div>It would be interesting to see some profile data on this to see what,<br>if anything, in BDB/Elephant could be improved.</blockquote><div><br></div><div>Do you want profile results from my package, or from Elephant internals? Either way, I have attached to profile reports. I hope you find them helpful.</div>
<div><br></div></div></div></span><div class="gmail_quote">On Thu, Jan 8, 2009 at 5:02 AM, Ian Eslick <span dir="ltr"><<a href="mailto:eslick@media.mit.edu">eslick@media.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
By the way, a write through mode is complex because if a transaction<br>
is rolled back your index could differ from your memory state so you<br>
would then have to keep track if slot writes to undo them on rollback...</blockquote><div><br></div><div>I don't currently (or expect to) rollback changes, so this isn't an issue with my particular application.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Are you caching blocks of objects for short term operations or long<br>
term ones?<br></blockquote></div><div><br></div>I would like to cache all objects in the current room, so the only major context switches should be when the player moves between rooms. So long term.<br clear="all"><br>-- <br>
Elliott Slaughter<br><br>"Any road followed precisely to its end leads precisely nowhere." - Frank Herbert<br>