Re: [sqlite] Fastest concurrent read-only performance (+ threads vsprocesses) [BUG?]

Absolutely. For what I'm trying to do, and given my experiments thus far, I would love to replicate the performance of the one-query/thread-per-process concurrency in the multithreaded case, foregoing the resource optimisations (shared cache etc.) and just having each query/thread do

Re: [sqlite] Fastest concurrent read-only performance (+ threads vsprocesses) [BUG?]

"Marcus Grimm" schrieb im Newsbeitrag news:4b9a01e8.2060...@medcom-online.de... > Increasing the number of threads does affect the overall > read performance slightly, example: > 1 Thread: 11.2 sec > 16 Threads: 8.2 sec > Single Process: 11sec. > > I still would expect

Re: [sqlite] Fastest concurrent read-only performance (+ threads vsprocesses) [BUG?]

Just to be clear, from my point of view at least, the big difference is between: - Multiple threads performing concurrent queries (with or without the shared cache) vs - Multiple processes performing concurrent queries In the latter case (for a number of queries chosen to lie within the

Re: [sqlite] Fastest concurrent read-only performance (+ threads vsprocesses) [BUG?]

Hi again, I have played again with some variations of the speed test: I'm not able to reproduce the reported behavior that a single process queries faster than a single thread. During my tests I don't get a big difference, even when I turn off some of the locking via SQLITE_OPEN_NOMUTEX. I have

Re: [sqlite] Fastest concurrent read-only performance (+ threads vsprocesses) [BUG?]

Hi Luke, Luke Evans wrote: > Hi Marcus, > > Well, I'd certainly be interested in looking at your code. Can you mail a > zip, or post to a web or file hosting site? Thanks. ok, please try this: http://www.exomio.de/SqliteSpeedTest.c I havent tried yet to compare the numbers when using one

Re: [sqlite] Fastest concurrent read-only performance (+ threads vsprocesses) [BUG?]

Hi Marcus, Well, I'd certainly be interested in looking at your code. Can you mail a zip, or post to a web or file hosting site? Thanks. Your results seem to broadly agree with mine: multithreaded querying can save a percentage of time (10-30%?) over the same queries issued serially with no

Re: [sqlite] Fastest concurrent read-only performance (+ threads vsprocesses) [BUG?]

I have followed the discussion about this issue with interest since my usage of sqlite involves threads and sharedcache mode as well. I have also generated a little speed test program that uses multible threads and shared cache to read *some* rows out of the sqlite DB. It might not help here but

Re: [sqlite] Fastest concurrent read-only performance (+ threads vsprocesses) [BUG?]

Well, I guess this is looking more an more like a bug then. I just went to the sqlite.org site to find out how I log a bug and it referred me back to here. Perhaps this means I just need to *DECLARE BUG* here ;-) Actually, I'll probably have some time soon to try out a profiler to see if I can