> In any case we seem to be settling to a long term
> sustained rate of
> about 40 flushes per second for WinXP. Since SQLite
> is getting only 10
> inserts per second, it seems to me that SQLite must
> be doing about 4
> flushes per insert. Does that seem right to you
> Richard?
For what
On 5/4/06, Dennis Cote <[EMAIL PROTECTED]> wrote:
It seems *really* strange that deleting the file would reduce the
average run time of the 1 loop case by more than 60 seconds. Neither
overwriting the file or deleting the file should take anywhere near this
long. These are small files of
Doug Currie wrote:
Add the line:
DeleteFile("test.txt");
in front of the CreateFile() call...
Doug,
This does make a difference. I thought that the CREATE_ALWAYS flag to
CreateFile would delete any existing file, but upon further
investigation I found out that what it does is open
Hi,
- Original Message -
From: "Dennis Cote" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Thursday, May 04, 2006 2:27 PM
Subject: Re: [sqlite] SQLite :memory: performance difference between v2 and
v3?
> All,
>
> More mysteries. To investig
Thursday, May 4, 2006, 1:27:49 PM, Dennis Cote wrote:
> More mysteries. To investigate this low insert performance under WinXP I
> wrote a simple test program that loops writing one character to a file
> and then flushing the file. The strange thing is that it seems to
> alternate between two
This program is almost completely I/O bound. It spends all its time
sleeping so its CPU usage is nearly zero. There might be some disk
contention from other programs, but I would think that should be fairly
constant. I am re-testing with longer run times to check this.
You give up your time
Jay Sprenkle wrote:
Initially performance is good but the degrades?
Some other processes must be sucking up cpu time?
Jay,
This program is almost completely I/O bound. It spends all its time
sleeping so its CPU usage is nearly zero. There might be some disk
contention from other programs,
--- Dennis Cote <[EMAIL PROTECTED]> wrote:
> All,
>
> More mysteries. To investigate this low insert
> performance under WinXP I
> wrote a simple test program that loops writing one
> character to a file
> and then flushing the file. The strange thing is
> that it seems to
> alternate between
On 5/4/06, Dennis Cote <[EMAIL PROTECTED]> wrote:
All,
More mysteries. To investigate this low insert performance under WinXP I
wrote a simple test program that loops writing one character to a file
and then flushing the file. The strange thing is that it seems to
alternate between two
All,
More mysteries. To investigate this low insert performance under WinXP I
wrote a simple test program that loops writing one character to a file
and then flushing the file. The strange thing is that it seems to
alternate between two different run times as shown below. This is for 6
> > Good ol' gprof.
> > It works as well today as it did 15 years ago.
--- Bill KING <[EMAIL PROTECTED]> wrote:
> Unless your app (and the stuff you want to profile) is multi-threaded. Ugh.
So true. Valgrind is your friend with multithreaded code.
Quantify used to good when Pure Software owned
Using the latest CVS and -O2, the :memory: database test with
100K inserts in a transaction completes in 6.921s.
:memory: inserts are now just 15% slower when transactions
are not used, as opposed to 7 times slower in yesterday's CVS.
The timings for 100K inserts in a transaction with the
Joe Wilson wrote:
>> Just curious: what did you use to generate the
>> profile? (i.e. which profiler?)
>>
>
> Good ol' gprof.
> It works as well today as it did 15 years ago.
>
>
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best
> Just curious: what did you use to generate the
> profile? (i.e. which profiler?)
Good ol' gprof.
It works as well today as it did 15 years ago.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
> > profile results with dirty pages fix:
> >
> > % cumulative self self
> total
> > time seconds secondscalls ms/call
> ms/call name
> > 9.20 0.31 0.31 100011 0.00
> 0.03 sqlite3VdbeExec
> > 7.42 0.56 0.25 4849544 0.00
The results below are for a non-optimized build.
With -O2, the same :memory: no-outer-BEGIN/COMMIT benchmark is 6 times faster
(7.953s now versus
47.828s with yesterday's CVS).
--- Joe Wilson <[EMAIL PROTECTED]> wrote:
> > Can you rerun your tests with the latest CVS check-in
> > and let me
> Can you rerun your tests with the latest CVS check-in
> and let me know if it makes a difference?
With the latest CVS, Dennis' :memory: database test without outer BEGIN/COMMIT
is now 4.3 times
faster on my machine (58.1s before, 13.4s now).
profile results with dirty pages fix:
%
Dennis Cote <[EMAIL PROTECTED]> wrote:
>
> My results are summarized below.
>
Can you rerun your tests with the latest CVS check-in
and let me know if it makes a difference?
--
D. Richard Hipp <[EMAIL PROTECTED]>
Ivan Voras wrote:
When using a file the difference is much smaller, but
still there: ~70 qps with sqlite3, ~90 qps with
sqlite2.
I also noticed that your values for this case are much higher than mine,
which are 10 and 13 ips respectively. I realize that you are using a
different OS
> Does it only happen with a :memory: database or even
> if you use a
> file?
When using a file the difference is much smaller, but
still there: ~70 qps with sqlite3, ~90 qps with
sqlite2.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the
--- Erik Jensen <[EMAIL PROTECTED]> wrote:
> Does it only happen with a :memory: database or even
> if you use a
> file?
I'll test it this evening (but I need a :memory:
database for my application)
> With version of the v3 lib did you use?
It's 3.3.5.
> I'm asking because i noticed a similar
IV> I've spent a long time debugging low performance of an
IV> application that uses :memory: database and have found
IV> that sqlite v2 is much faster than v3. After some
IV> digging around it seems that even two proof-of-concept
IV> programs that are identical except for used SQLite
IV> version
> In any case, when doing any kind of benchmarking that involves disk
access,
> you must clear the OS disk cache so that the algorithm used by the OS is
> removed from the equation (and also to be able to compare results),
otherwise
> all you're doing is benchmarking a moving target.
In Linux,
- Original Message
From: Jay Sprenkle <[EMAIL PROTECTED]>
On 5/1/06, Ivan Voras <[EMAIL PROTECTED]> wrote:
> > I've spent a long time debugging low performance of an
> > application that uses :memory: database and have found
> > that sqlite v2 is much faster than v3. After some
> >
24 matches
Mail list logo
