Thanks Stephen for this.  It seems like we're closing in on completion here with the final step being Stephen's team looking at the lock issue and to advise Guardian as to fixes/changes/etc that we (Guardian) would implement.<div>

<br></div><div>Stephen - can you provide a timeframe for your locking review?<br><div><br></div><div>HC, Abel - please advise if this is correct.  Also, do we have work to do bringing to the repository up-to-date?<br><div>

<br></div><div><br></div><div>Dave</div><div><br clear="all"><div>David M. Oliver | <a href="mailto:david@olivercoady.com" target="_blank">david@olivercoady.com</a> | <a href="http://olivercoady.com" target="_blank">http://olivercoady.com</a> | <a href="http://dmo.tel" target="_blank">http://dmo.tel</a> | @davidmoliver | +1 970 368 2366</div>


<br><br><div class="gmail_quote">On Thu, Jan 17, 2013 at 10:58 PM, Stephen Lombardo <span dir="ltr"><<a href="mailto:sjlombardo@zetetic.net" target="_blank">sjlombardo@zetetic.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hello Hans,<br>
<div class="im"><br>
On 2013-01-15, Hans-Christoph Steiner wrote:<br>
> I'm integrating the IOCipher patch now, did you have any tests written up for<br>
> that already?  I renamed begin() and complete() to beginTransaction() and<br>
> completeTransaction() since the words 'begin' and 'complete' seemed too vague<br>
> in the context of the VirtualFileSystem class.  We'll work to document that so<br>
> people can make good use of it.<br>
<br>
</div>We made several changes to the VfsTest project to add timings etc. to facilitate testing. The performance testing was still a bit manual, since we had to change the settings in libsqlfs, build a libiocipher.so, and then re-deploy the app, but it might be useful in the future. We'll commit it all up to a github repo tomorrow.<br>


<div class="im"><br>
> It would great if you could spend the remaining time (~10 hours) working on<br>
> improving the lock situation so that we can have concurrent reads, or maybe<br>
> even SQLite3 3.7's WAL, if that's not too ambitious.  This chunk is probably<br>
> more complicated than the write work you just did, so it might just be that<br>
> you end up giving us direction for how to implement it.<br>
<br>
</div>This sounds good, we should have some time to look into the lockign, threading, and WAL setup tomorrow and Monday.<br>
<div class="im"><br>
> FYI, I added read<br>
> speed tests to tests/c_perf.c and they are already a lot faster than writes,<br>
> looks like they take about 40-50% of the time of a similarly arranged write.<br>
<br>
</div>Ah, read tests are an excellent idea. That sounds consistent with what I would expect, there is a lot of extra overhead on the write side for each block read, update, write and commit. That should speed up a bit with WAL due to the way the writes occur as it cuts down on the number of pages that have to be written in each transaction by omitting the rollback journal.<br>


<br>
Cheers,<br>
Stephen<br>
</blockquote></div><br></div></div></div>