<div class="gmail_quote">Hi,</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Dec 29, 2008 at 2:46 PM, Ian Eslick <span dir="ltr"><<a href="mailto:eslick@media.mit.edu" target="_blank">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">
<br>
I checked the cache-checkout model to elephant-unstable.<br></blockquote><div><br></div><div>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.</div>
</div><br><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">
- On checkout, the cached slots of the checked-out object behaves<br></blockquote><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">
like a standard built-in object, although with MOP overhead on<br></blockquote><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">
accesses (see below)<br></blockquote><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">
- Write operations are also cached<br></blockquote><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">
- The persistent-checkin operation write the current cached slot state<br></blockquote><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">
to the DB<br></blockquote><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 sync a currently checked out object to make its state<br></blockquote><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">
persistent<br></blockquote><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">
- Checkout can be cancelled<br></blockquote><br><div>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:</div>
<div><br></div><div><div>(when (eq (ele::%cache-style (class-of object)) :checkout)</div><div> (ele:persistent-checkout object))</div></div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.)</div>
<div><br></div>
<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">
Standard: 25M/sec<br>Cached: 7M/sec<br>Persistent (within a transaction): 140k/sec<br><br>Cached slot access is now only 4x slower than standard slot access<br>Persistent slot access is about 50x slower than cached slot access</blockquote>
</div><div><br></div><div>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.</div><div><br>
</div><div>Thanks again.</div><div><br>
-- <br>Elliott Slaughter<br>
<br>"Any road followed precisely to its end leads precisely nowhere." - Frank Herbert<br>
</div>