Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

> Long story short - I suspect the open-call, to be the "blocker" > in your "SharedCache-Mode=Off"-scenario. If database file is pretty large, query reads a lot of data while executing and all data read fit into database cache configured then I think I/O will be the main difference between

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

"Luke Evans" schrieb im Newsbeitrag news:5d6df6e4-c817-4788-a2a2-87dc5e32f...@me.com... > Thanks very much for your notes Olaf. > > I've done as you suggest... I already had SQLITE_THREADSAFE=2 > defined, but didn't have the SQLITE_OMIT_SHARED_CACHE > asserted (assuming private

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

Thanks very much for your notes Olaf. I've done as you suggest... I already had SQLITE_THREADSAFE=2 defined, but didn't have the SQLITE_OMIT_SHARED_CACHE asserted (assuming private cache to be the default). The Objective-C method that each thread calls to do the actual querying (bracketed

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

"Luke Evans" schrieb im Newsbeitrag news:3be16206-d0c6-4041-a3a6-ca3c069ee...@me.com... > It's Objective-C, but all the SQLite interfacing bits are pure C > directly driving the SQLite API compiled into the program > (3.6.22 amalgamation). Just to make sure ... do you really

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

It's Objective-C, but all the SQLite interfacing bits are pure C directly driving the SQLite API compiled into the program (3.6.22 amalgamation). On 2010-03-04, at 11:25 AM, Pavel Ivanov wrote: > What language is that? Probably wrapper for this language introduces > its own mutexes. >

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

What language is that? Probably wrapper for this language introduces its own mutexes. Pavel On Thu, Mar 4, 2010 at 2:07 PM, Luke Evans wrote: > Thanks guys. > > Well, I had played with turning off the shared cache, and have just done so > again. > What I'm actually seeing is

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

Thanks guys. Well, I had played with turning off the shared cache, and have just done so again. What I'm actually seeing is serialisation (or at least some apparently quite coarse-grained synchronisation). Here's some logging output on my Mac. The start/finished messages are logged by each

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

On Mar 5, 2010, at 12:50 AM, Luke Evans wrote: > Hi SQLiters, > > We're currently investigating SQLite in an application that needs to > issue a batch of queries (SELECTs) before doing some work with all > the data returned. > > I have been trying to figure out the fastest way to get the >

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

> The process experiment seems to confirm that very fast independent parallel > queries can be made on the same database, but clearly I would like the same > behaviour using multiple threads (and probably connections) in the same > process.  Is this possible with some specific configuration of