site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hi Mark, On 28-aug-2006, at 12:48, Mark Gilbert wrote: Regards, Sjoerd. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... My app accesses the same SQlite database from several threads, and in order to accommodate this I currently open and close the database on each access, and the various threads will wait when the database is busy on another thread. This all works OK, but I am finding performance issues, which I think may be related to the opening and closing. My idea is to limit access to the database to a single intermediate thread, with each other thread passing their requests through the 'owner' thread for the SQLite database. My hope is that this thread can leave the database permanently open with a large cache size and consequently speed things up. Would anyone with experience in SQLite performance care to comment if this is a good strategy to improve performance ? Currently an open/access/close cycle is taking around 250mSecs, even though its a tiny database and fairly simple SQLite requests. I may need to do several database accesses per second, so currently its all stacking up. First of all, I don't think this is the correct place to ask that question. Secondly, this sounds an awful lot like you're trying to put a concurrency layer upon SQLite. The developers themselves note that applications requiring high concurrency should probably use a "real" RDBMS in favor of SQLite (http://www.sqlite.org/ whentouse.html). But if that is not an option, then this might just do the trick for you (by using some queueing mechanism that basically serializes database access). As you may know SQLite has a very pessimistic locking mechanism: any access to the database (read and/ or write) locks the entire database from other processess (read and/ or write). This email sent to site_archiver@lists.apple.com