Re: [sqlite] :memory: performance in sqlite 3.6

2013-02-22 Thread Seebs
On 22 Feb 2013, at 8:31, Eduardo Morras wrote: The only thing i can think that explain it is compilation options, specifically SQLITE_TEMP_STORE=0. If you do pragma temp_store=2, does it work better? Nope. I did check all this stuff out, got ideas from people in the #sqlite IRC channel,

Re: [sqlite] :memory: performance in sqlite 3.6

2013-02-22 Thread Seebs
On 22 Feb 2013, at 8:07, Stephen Chrzanowski wrote: I think I missed something; For clarification, you mention that you're running the tests and are monitoring memory use but (And here's what I'm missing) you don't see a memory load against the application? I do see a memory load against

Re: [sqlite] :memory: performance in sqlite 3.6

2013-02-22 Thread Eduardo Morras
On Wed, 20 Feb 2013 12:06:17 -0600 Seebs wrote: > On 20 Feb 2013, at 11:47, Simon Slavin wrote: > > > On 20 Feb 2013, at 5:32pm, Seebs wrote: > > > >> First: The SQL is completely trivial. > >> Second: I am not having performance problems with sqlite, I am

Re: [sqlite] :memory: performance in sqlite 3.6

2013-02-22 Thread Stephen Chrzanowski
I think I missed something; For clarification, you mention that you're running the tests and are monitoring memory use but (And here's what I'm missing) you don't see a memory load against the application? If you're using the :MEMORY: database, throwing anything at it should bump up the count

Re: [sqlite] :memory: performance in sqlite 3.6

2013-02-20 Thread Seebs
On 20 Feb 2013, at 11:47, Simon Slavin wrote: On 20 Feb 2013, at 5:32pm, Seebs wrote: First: The SQL is completely trivial. Second: I am not having performance problems with sqlite, I am having performance problems with :memory:. Performance on files is lovely. This

Re: [sqlite] :memory: performance in sqlite 3.6

2013-02-20 Thread Simon Slavin
On 20 Feb 2013, at 5:32pm, Seebs wrote: > First: The SQL is completely trivial. > Second: I am not having performance problems with sqlite, I am having > performance problems with :memory:. Performance on files is lovely. This normally means that your computer has very little

Re: [sqlite] :memory: performance in sqlite 3.6

2013-02-20 Thread Seebs
On 20 Feb 2013, at 5:20, Eduardo Morras wrote: Execution time doing what?, Waiting for I/O? How do you get execution time? What sql are you doing? I'm using sqlite3_profile and summing the reported times in nanoseconds. Don't run with synchronous off, it's only calms the symptom, don't

Re: [sqlite] :memory: performance in sqlite 3.6

2013-02-20 Thread Seebs
On 20 Feb 2013, at 3:59, Clemens Ladisch wrote: Seebs wrote: I tried ... an in-memory database. What I observed was a very, very, large slowdown. We're talking 10MB of database That database would be in the OS's file cache anyway. It should. Problem is, there's a nearby program that was

Re: [sqlite] :memory: performance in sqlite 3.6

2013-02-20 Thread Eduardo Morras
On Tue, 19 Feb 2013 16:05:14 -0600 Seebs wrote: > I'm afraid I haven't got a nicely isolated reproducer for this. > > I maintain a package, called pseudo, which includes a server built > around an sqlite database. In the process of debugging some performance > issues, I did

Re: [sqlite] :memory: performance in sqlite 3.6

2013-02-20 Thread Clemens Ladisch
Seebs wrote: > I tried ... an in-memory database. > What I observed was a very, very, large slowdown. > We're talking 10MB of database That database would be in the OS's file cache anyway. > 3. It is dramatically reduced in degree by pragma page_size = 8192. The default cache size is measured

[sqlite] :memory: performance in sqlite 3.6

2013-02-19 Thread Seebs
I'm afraid I haven't got a nicely isolated reproducer for this. I maintain a package, called pseudo, which includes a server built around an sqlite database. In the process of debugging some performance issues, I did some casual benchmarking. One of the first things I tried was an in-memory