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
"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
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
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
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
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
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
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
> 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.
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
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
"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
"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
13 matches
Mail list logo