In my experience, and from extensively working with couchdb[0] , to way to improve performance of software that relies on sqlite is to make the writes as short as possible and more granular. Since reads IIRC by default return immediately if there's no writing thread blocking, this has quite nice results and is already utilized by projects like Axiom[1].
-Sivan [0]: (which could be interesting to test instead of sqlite if we're going to the proper async direction, being erlang it should not heave issues to run on mobile targets and is already running on iOS and Android, also it is highly performent if writes are un-conflicting and the current version of a document is represented by a view collecting revisions ) [1]: http://pypi.python.org/pypi/Axiom/0.6.0 On Wed, Jan 19, 2011 at 8:56 PM, Bernd Stramm <bernd.str...@gmail.com> wrote: > On Wed, 19 Jan 2011 20:31:35 +0200 > "Ville M. Vainio" <vivai...@gmail.com> wrote: > >> On Wed, Jan 19, 2011 at 7:58 PM, Bernd Stramm >> <bernd.str...@gmail.com> wrote: >> >> > Doing the writes asynchronously can improve response time for the >> > parts of a system that don't wait for these particular write >> > operations. >> >> Can you elaborate on that? Why would a process wait for a particular >> write operation, instead of just wanting to get access to the current >> state of the database? > > The process that issues the write may well assume that the data it just > wrote are part of the current state of the database. If it doesn't wait > for the write, this assumption is not necessarily correct. In > particular, a read for the data changed by the write issued (but not > completed) will reflect the old state. > > The writes do not go any faster. The difference is just that normally > sqlite blocks the entire writing thread from doing anything else. Not > just any other sqlite operations, but anything. No Qt event loop, for > example. > >> >> > It doesn't actually gain performance in the sense that write >> > operations don't complete any faster. >> >> It unblocks the process that is flushing the transaction, allowing it >> to process new requests. If you flush the data for a second and you >> get a new request, you lose that second (instead of being able to >> serve the request immediately). >> >> What you lose is "Durability" aspect of ACID. >> > > > > -- > Bernd Stramm > bernd.str...@gmail.com > > _______________________________________________ > MeeGo-dev mailing list > MeeGo-dev@meego.com > http://lists.meego.com/listinfo/meego-dev > _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
