<div class="gmail_quote">On Sun, Dec 28, 2008 at 2:09 PM, 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;">
I implemented a quick check-in/check-out protocol for persistent </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
objects.</blockquote><div><br></div><div>Nice. Mind sharing?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">A standard-object slot allows about 50M updates-sec<br>

A persistent-object slot (inside a txn) is about 60k updates-sec<br>
A cached persistent-object slot is about 3M updates-sec</blockquote><div><br></div><div>I implemented my own version of caching using Alex's suggestion (with slot defs caching their values in hash tables).</div><div>
<br></div><div>With a simple loop (code attached), I get about 30M updates per second (Hz) for standard slots, about 30 kHz for persistent slots, and about 2.4 MHz using my caching scheme.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The slot access protocol adds about 10x overhead per slot read but the<br>
cached access is about 50x faster than the pure persistent query.<br>
I'll see if there are some easy opportunities to speed things up.</blockquote><div><br></div><div>I observed about the same performance differences (although I saw closer to an 100x difference between persistence and caching).</div>
<div><br></div><div>My method uses hash table lookups for slot reads, which makes me wonder if I'd get better performance by using a slot caching protocol more similar to the default implementation.</div><div><br></div>
<div>Anyways, using cached slots in my game results in a 2x speed increase, although it still runs 2x to 3x slower than the completely in-memory version. I guess I have other performance concerns to think about than just slot reads.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d">Ian<br>
<br>
On Dec 28, 2008, at 2:05 AM, Elliott Slaughter wrote:<br>
<br>
</div><div><div></div><div class="Wj3C7c">> There are several replies to my original query, so I will attempt to<br>
> address all of them here.<br>
><br>
> On Wed, Dec 24, 2008 at 2:31 PM, Ian Eslick <<a href="mailto:eslick@media.mit.edu">eslick@media.mit.edu</a>><br>
> wrote:<br>
> A couple of quick thoughts on your problem:<br>
><br>
> 1) Are you wrapping the critical sections of your code in with-<br>
> transaction?  This causes all database pages you touch to be cached<br>
> within the body of the transaction.  This avoids all 'sync' operations<br>
> and transaction setup/teardown caused by a read/write slot operation<br>
> that takes place outside a with-transaction body.<br>
><br>
> I currently wrap the contents of each frame update in with-<br>
> transaction. Each frame consists of updating 100 objects on the<br>
> screen (which by my estimation ought to be about 20 slot reads and 2<br>
> writes), so I ought to be doing about 2000 slot reads each frame and<br>
> 200 writes.<br>
><br>
> Wrapping the entire game loop in with-transaction increases<br>
> performance by about 10%. I also tried<br>
><br>
> (db-env-set-flags (controller-environment *store-controller*) 1 :txn-<br>
> nosync t)<br>
><br>
> as suggested in the manual, with a similar (about 10%) performance<br>
> increase.<br>
><br>
> 2) If you are doing this, have you increased your BDB cache size to<br>
> ensure you can cache your key working set?<br>
><br>
> It should already be large enough, but just for kicks I increased it<br>
> from 2 to 10 MB, resulting in a performance increase of about 3%.<br>
><br>
> 3) If yes, do you have significant contention between reads and writes<br>
> for certain data structures that are causing transactions to be<br>
> aborted.  Perhaps you can refactor around this.<br>
><br>
> This is a single-threaded (and single-process) app. I don't see how<br>
> I could possibly have contention for the db.<br>
><br>
> Ian<br>
><br>
> And thanks to both Leslie and Alex for suggesting caching methods. I<br>
> will probably try to implement something along the lines of Alex's<br>
> suggestion, as that makes sense and should be simple enough (for the<br>
> single threaded model, which is sufficient for me).<br>
><br>
><br>
> Thanks again for all the help. I'll report back either when I have<br>
> something working or I've run into another wall.<br>
><br>
> --<br>
> Elliott Slaughter<br>
><br>
> "Any road followed precisely to its end leads precisely nowhere." -<br>
> Frank Herbert<br>
</div></div><div><div></div><div class="Wj3C7c">> _______________________________________________<br>
> elephant-devel site list<br>
> <a href="mailto:elephant-devel@common-lisp.net">elephant-devel@common-lisp.net</a><br>
> <a href="http://common-lisp.net/mailman/listinfo/elephant-devel" target="_blank">http://common-lisp.net/mailman/listinfo/elephant-devel</a><br>
<br>
<br>
_______________________________________________<br>
elephant-devel site list<br>
<a href="mailto:elephant-devel@common-lisp.net">elephant-devel@common-lisp.net</a><br>
<a href="http://common-lisp.net/mailman/listinfo/elephant-devel" target="_blank">http://common-lisp.net/mailman/listinfo/elephant-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Elliott Slaughter<br><br>"Any road followed precisely to its end leads precisely nowhere." - Frank Herbert<br>