Re: [sqlite] In-memory DB slower than disk-based?

not in practice. -Vern -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Stephen Chrzanowski Sent: Thursday, August 07, 2014 5:30 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] In-memory DB slower than disk-based

Re: [sqlite] In-memory DB slower than disk-based?

It "smells" like that you're running into general timing issues, especially if you're consistent with how long it takes to put info into the database. If we were to take your scenario of 100 threads of writing to memory, bashing the hell out of the database for writes, the first thread is going

Re: [sqlite] In-memory DB slower than disk-based?

Real hardware. 27” iMac (native BootCamp running Win 7) with 3.4 GHz Intel Core i7 quad-core processor. And my mistake: 24 GB of RAM, not 20. Anytime I’ve looked at the app while it’s running, it’ll take 5 to 15 MB at most, depending on how many threads I give it. -Vern

Re: [sqlite] In-memory DB slower than disk-based?

Jim, The primary table in the database has 5 columns, and has at most about 4,000 entries during stress-testing. (Although in tests involving even only about 600 entries, the results were the same.) There are a few other tables that would be much smaller. Nothing that should stress any

Re: [sqlite] In-memory DB slower than disk-based?

On 7 Aug 2014, at 3:47am, Jim Callahan wrote: > [various questions] In addition, is this real hardware, or is it a simulated or virtual machine ? Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org

Re: [sqlite] In-memory DB slower than disk-based?

What is the system memory utilization? If the in-memory database overloads the real memory the frantic os virtual memory paging (thrashing) could slow everything down. >From your use scenario it sounds like your database shouldn't be that large, but how large is the database? and how large is the

Re: [sqlite] In-memory DB slower than disk-based?

On 6 Aug 2014, at 11:00pm, big stone wrote: > I too noticed disappointing improvements by going ":memory:". > But, it seems also very dependent of the compilation options and the > version of SQLite you use. > > sometimes, gain is roughly 0% > sometimes, gain can be 40%.

Re: [sqlite] In-memory DB slower than disk-based?

Hi, I too noticed disappointing improvements by going ":memory:". But, it seems also very dependent of the compilation options and the version of SQLite you use. sometimes, gain is roughly 0% sometimes, gain can be 40%. ==> You may try with a more recent version of SQLite than 3.7.15.2.

Re: [sqlite] In-memory DB slower than disk-based?

Thanks for the replies, Fabian and Richard. It’s definitely ‘good enough’ performance as-is, I mainly wanted to see if I was doing something clearly wrong, or if my results were surprising. Given that they’re not, I’m happy to move on. Thanks again, -Vern IMPORTANT WARNING: This message is

Re: [sqlite] In-memory DB slower than disk-based?

On Wed, Aug 6, 2014 at 2:51 PM, Jensen, Vern wrote: > *bump* > > Anyone? > I don't think anybody has any information for you Vern. So much depends on the details of your setup that it is hard to speculate what might be going wrong. -- D. Richard Hipp d...@sqlite.org

Re: [sqlite] In-memory DB slower than disk-based?

On 8/6/2014 11:51 AM, Jensen, Vern wrote: *bump* Anyone? Not sure if this is your problem, but this kind of load puts a lot of stress on SQLite's page cache, which might well perform worse than your OS'es page cache (used for "real" disk IO) does, especially under high contention. Also,

Re: [sqlite] In-memory DB slower than disk-based?

*bump* Anyone? -Vern Vern Jensen Software Engineer Artificial Intelligence in Medicine (AIM) Program jens...@cshs.org Office: 310-423-8148 :: Fax: 310-423-0173 On Aug 4, 2014, at 12:02 PM, Jensen, Vern

[sqlite] In-memory DB slower than disk-based?

Hey all! We use SQLite (3.7.15.2) as the backend for a server that provides floating licenses for our software. I've recently written a stress-testing framework that starts up any number of threads, and hits the server with multiple requests per thread. While being stress-tested in this way,