> On Oct 28, 2014, at 3:10 AM, Alexander Selling <[email protected]> > wrote: > > I understand that the test is super naive, there's caching involved that > would render the test useless. However, does cbl do bulk fetches? Is that > what a transaction is for in this case?
No — transactions only affect writes, not reads. The major effect of -inTransaction: is to start a SQLite transaction before calling the block, and end the transaction after the block. This groups all the writes into a single transaction, whereas by default SQLite treats every INSERT/UPDATE/DELETE as its own transaction. The performance benefit is because committing a transaction to disk is expensive. To meet its durability guarantees, SQLite has to flush all of its writes to the kernel and then force the filesystem to flush all those writes to the physical storage medium, not returning until the writes are complete. For reasons involving arcane details of the way disk controllers work, this can take anywhere up to hundreds of milliseconds. Not a cost you want to incur many times in a row if you're saving a lot of documents! (When we switch to ForestDB the details will differ, but ForestDB also has transactions. Although from what I can tell, it has a lot less overhead when committing a transaction. Not sure why.) But back to what you actually asked about :) Transactions have no effect on read performance. —Jens -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/495A08F2-55AF-41BA-8339-4939BA0BC722%40couchbase.com. For more options, visit https://groups.google.com/d/optout.
