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

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

> Pavel, regarding the question about VFS, I'm not using one to my knowledge > and have set the "name of VFS module" to NULL in sqlite3_open_v2.  Maybe NULL > means I'm using the standard VFS, but in any case, not a "non-standard" one. If you pass NULL you use _default_ VFS, not a standard one.

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

Hi guys, Had to take a break for a couple of days from my SQLite experiments, but back on it now. Pavel, regarding the question about VFS, I'm not using one to my knowledge and have set the "name of VFS module" to NULL in sqlite3_open_v2. Maybe NULL means I'm using the standard VFS, but in

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

Just a bit of thought here: if opening was at fault then 5 queries started at the same time would finish in different times (first open executes, then while first query executes second open can be executed, then first query already executed while second is still in works etc). So blocking delays

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

"Pavel Ivanov" schrieb im Newsbeitrag news:f3d9d2131003051131k23c7b61cueda0bcc72e6aa...@mail.gmail.com... Oops, pressed send unintentionally... > > Long story short - I suspect the open-call, to be the "blocker" > > in your "SharedCache-Mode=Off"-scenario. > If database

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

"Pavel Ivanov" schrieb im Newsbeitrag news:f3d9d2131003051131k23c7b61cueda0bcc72e6aa...@mail.gmail.com... > 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