[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] Why SQLite take lower performance in multi-thread SELECTing?
From:       Richard Hipp <drh () sqlite ! org>
Date:       2015-10-31 19:45:38
Message-ID: CALwJ=MxMv-ejMkcL+62HeZJuW3QyehR4TDt-3-nsQ5DcMj9c_w () mail ! gmail ! com
[Download RAW message or body]

On 10/30/15, sanhua.zh <sanhua.zh@foxmail.com> wrote:
> Hi, all
> I use SQLite in iOS. I found that SQLite will take lower performancein
> multi-thread SELECTing.
> Here is my test result,
> It costs 0.11s to select 100,0000 elements,in 1-thread SELECTing:
> But the sameIn 4-thread SELECTing, it costs 0.2s avg.
>
>
> This test run on iPhone 6s.
> You can see that 4-thread is take almost twice slower than 1-thread.
> I know multi-thread might costs the system resource, but this result is much
> slower than what I excepted.
> Is there some race condition in SQLite or I write the wrong code ?
>

You *might* be doing something wrong.  It is hard to say without
seeing your code.

But the 2x slowdown might be entirely due to thread contention and
mutexing.  Remember that the flash memory filesystem on iOS has finite
bandwidth, and all the threads in the world will not increase that
bandwidth.  The extra threads just cause extra overhead which ends up
slowing everything down.

-- 
D. Richard Hipp
drh@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[prev in list] [next in list] [prev in thread] [next in thread]