@sanhua> If you can, just for testing, use the SQLite backup mechanism to
copy the database to memory, then run your transactions off the memory
version.  This will get rid of disk IO with the exclusion of the OS
swapping to memory.  This will tell you if you're running into some kind of
thread locking or if you're running into a disk IO issue.

I have absolutely no clue about the back end of iOS (Other than it is linux
based) so I don't know what it offers for threaded operations, or if the
library you're using has threaded capabilities.



On Sun, Nov 1, 2015 at 11:25 PM, Simon Slavin <slavins at bigfraud.org> wrote:

>
> On 2 Nov 2015, at 3:48am, sanhua.zh <sanhua.zh at foxmail.com> wrote:
>
> > I thought it might be storage contention, too.
> > BUT, as the documentation of SQLite said, in ?DELETE? mode, SELECTing do
> read for disk only.
>
> Even reading needs the attention of the disk.  You tell the disk what you
> want to read and it has to find that piece of disk, read it, and give the
> result to you.  It cannot answer four requests at once so while it's
> answering one, the other threads have to wait.
>
> (Yes disk is cached.  But that just moves the problem from the hard disk
> to the piece of software which handles the cache.  It cannot answer four
> questions at once.)
>
> Simon.
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

Reply via email to