database/sqlite
1
0
Fork 0
mirror of https://github.com/sqlite/sqlite.git synced 2025-07-30 19:03:16 +03:00
Code Activity

Prepare for Alpha-3 (CVS 265)

Browse Source 
FossilOrigin-Name: 9c9322eb46894860cd7c294cd19ce72614722a73
This commit is contained in:
drh
2001-09-25 01:50:59 +00:00
parent afa4a020f2
commit dd137a09d5
6 changed files with 326 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
Makefile.in
View File

@ -266,6 +266,9 @@ mingw.html: $(TOP)/www/mingw.tcl
tclsqlite.html: $(TOP)/www/tclsqlite.tcl tclsqlite.html: $(TOP)/www/tclsqlite.tcl
tclsh $(TOP)/www/tclsqlite.tcl >tclsqlite.html tclsh $(TOP)/www/tclsqlite.tcl >tclsqlite.html
speed.html: $(TOP)/www/speed.tcl
tclsh $(TOP)/www/speed.tcl >speed.html
# Files to be published on the website. # Files to be published on the website.
# #
@ -282,7 +285,8 @@ PUBLISH = \
c_interface.html \ c_interface.html \
crosscompile.html \ crosscompile.html \
mingw.html \ mingw.html \
tclsqlite.html tclsqlite.html \
speed.html
website: $(PUBLISH) website: $(PUBLISH)

2
VERSION
View File

@ -1 +1 @@
2.0-alpha-2 2.0-alpha-3

17
manifest
View File

@ -1,8 +1,8 @@
C Tests\sfor\sinserting\slots\sof\sdata\s(~64K)\sinto\sa\ssingle\srow\sof\sa\stable.\s(CVS\s264) C Prepare\sfor\sAlpha-3\s(CVS\s265)
D 2001-09-24T03:12:40 D 2001-09-25T01:50:59
F Makefile.in 18eea9a3486939fced70aa95b691be766c2c995d F Makefile.in fe9d96d6a7b04b3000a24692c2a3761840bbbf97
F README 51f6a4e7408b34afa5bc1c0485f61b6a4efb6958 F README 51f6a4e7408b34afa5bc1c0485f61b6a4efb6958
F VERSION 6942aa44940d2972bd72f671a631060106e77f7e F VERSION 17fadc361fb942d644f92116388409c937c9fa79
F configure aad857a97ca28a584228869186eb4cd7dbebbb3a x F configure aad857a97ca28a584228869186eb4cd7dbebbb3a x
F configure.in 0000c0d62beb47cae1d2d81a197c7fe6efd56a45 F configure.in 0000c0d62beb47cae1d2d81a197c7fe6efd56a45
F doc/lemon.html f0f682f50210928c07e562621c3b7e8ab912a538 F doc/lemon.html f0f682f50210928c07e562621c3b7e8ab912a538
@ -91,14 +91,15 @@ F www/c_interface.tcl 52ae81c89bf906b358e04857bd3f76b1a7f61c1b
F www/changes.tcl 7e5a04a59a417a9fd4c94ce38543adbca0e01937 F www/changes.tcl 7e5a04a59a417a9fd4c94ce38543adbca0e01937
F www/crosscompile.tcl c99efacb3aefaa550c6e80d91b240f55eb9fd33e F www/crosscompile.tcl c99efacb3aefaa550c6e80d91b240f55eb9fd33e
F www/dynload.tcl 02eb8273aa78cfa9070dd4501dca937fb22b466c F www/dynload.tcl 02eb8273aa78cfa9070dd4501dca937fb22b466c
F www/index.tcl d65c6eaf66afac5b8a4b0394f691be02a2c3be20 F www/index.tcl fd8ef2d78f22022d2baea03371a1add75d98d236
F www/lang.tcl d093693db5d4d7b7127d134807e4e65dea0e5dee F www/lang.tcl d093693db5d4d7b7127d134807e4e65dea0e5dee
F www/mingw.tcl fc5f4ba9d336b6e8c97347cc6496d6162461ef60 F www/mingw.tcl fc5f4ba9d336b6e8c97347cc6496d6162461ef60
F www/opcode.tcl 60222aeb57a7855b2582c374b8753cb5bb53c4ab F www/opcode.tcl 60222aeb57a7855b2582c374b8753cb5bb53c4ab
F www/speed.tcl 7320bb981f67a5ef18397cbfeb74fd3ac5f4e58f
F www/sqlite.tcl cb0d23d8f061a80543928755ec7775da6e4f362f F www/sqlite.tcl cb0d23d8f061a80543928755ec7775da6e4f362f
F www/tclsqlite.tcl 13d50723f583888fc80ae1a38247c0ab415066fa F www/tclsqlite.tcl 13d50723f583888fc80ae1a38247c0ab415066fa
F www/vdbe.tcl 0c8aaa529dd216ccbf7daaabd80985e413d5f9ad F www/vdbe.tcl 0c8aaa529dd216ccbf7daaabd80985e413d5f9ad
P bb4313a94bc079d072078f353e54f3804971060d P a462c85083d23aa34bd3d0c61d01062fc5ae8230
R 69829e6305936fff1b9496182feb41ef R 7b8aaac299ca08d5a78dcf95d8a2bf19
U drh U drh
Z 400cf1b054cf4870465ea4bfa97da0d6 Z 2a5bd12e8fd0e8799083fed248ef84d4

2
manifest.uuid
View File

@ -1 +1 @@
a462c85083d23aa34bd3d0c61d01062fc5ae8230 9c9322eb46894860cd7c294cd19ce72614722a73

5
www/index.tcl
View File

@ -1,7 +1,7 @@
# #
# Run this TCL script to generate HTML for the index.html file. # Run this TCL script to generate HTML for the index.html file.
# #
set rcsid {$Id: index.tcl,v 1.40 2001/09/20 12:32:53 drh Exp $} set rcsid {$Id: index.tcl,v 1.41 2001/09/25 01:51:00 drh Exp $}
puts {<html> puts {<html>
<head><title>SQLite: An SQL Database Engine In A C Library</title></head> <head><title>SQLite: An SQL Database Engine In A C Library</title></head>
@ -37,7 +37,8 @@ on disk.</p>
stored in a single disk file.</li> stored in a single disk file.</li>
<li>Atomic commit and rollback protect data integrity.</li> <li>Atomic commit and rollback protect data integrity.</li>
<li>Small memory footprint: about 12000 lines of C code.</li> <li>Small memory footprint: about 12000 lines of C code.</li>
<li>Much faster than version 1.0!</li> <li><a href="speed.html">Four times faster</a> than PostgreSQL.
Twice as fast as SQLite 1.0.</li>
<li>Very simple <li>Very simple
<a href="c_interface.html">C/C++ interface</a> requires the use of only <a href="c_interface.html">C/C++ interface</a> requires the use of only
three functions and one opaque structure.</li> three functions and one opaque structure.</li>

307
www/speed.tcl Normal file
View File

@ -0,0 +1,307 @@
#
# Run this Tcl script to generate the speed.html file.
#
set rcsid {$Id: }
puts {<html>
<head>
<title>Database Speed Comparison: SQLite versus PostgreSQL</title>
</head>
<body bgcolor=white>
<h1 align=center>
Database Speed Comparison
</h1>}
puts "<p align=center>
(This page was last modified on [lrange $rcsid 3 4] GMT)
</p>"
puts {
<h2>Executive Summary</h2>
<p>A series of tests are run to measure the relative performance of
SQLite version 1.0 and 2.0 and PostgreSQL version 6.4.
The following are general
conclusions drawn from these experiments:
</p>
<ul>
<li><p>
SQLite 2.0 is significantly faster than both SQLite 1.0 and PostgreSQL
for most common operations.
SQLite 2.0 is over 4 times faster than PostgreSQL for simple
query operations about 7 times faster for <b>INSERT</b> statements
within a transaction.
</p></li>
<li><p>
PostgreSQL performs better on complex queries, possibly due to having
a more sophisticated query optimizer.
</p></li>
<li><p>
SQLite 2.0 is significantly slower than both SQLite 1.0 and PostgreSQL
on <b>DROP TABLE</b> statements and on doing lots of small <b>INSERT</b>
statements that are not grouped into a single transaction.
</p></li>
</ul>
<h2>Test Environment</h2>
<p>
The platform used for these tests is a 550MHz Athlon with 256MB or memory
and 33MHz IDE disk drives. The operating system is RedHat Linux 6.0 with
various upgrades, including an upgrade to kernel version 2.2.18.
</p>
<p>
PostgreSQL version 6.4.2 was used for these tests because that is what
came pre-installed with RedHat 6.0. Newer version of PostgreSQL may give
better performance.
</p>
<p>
SQLite version 1.0.32 was compiled with -O2 optimization and without
the -DNDEBUG=1 switch. Setting the NDEBUG macro disables all "assert()"
statements within the code, but SQLite version 1.0 does not have any
expensive assert() statements so the difference in performance is
negligible.
</p>
<p>
SQLite version 2.0-alpha-2 was compiled with -O2 optimization and
with the -DNDEBUG=1 compiler switch. Setting the NDEBUG macro is very
important in SQLite version 2.0. SQLite 2.0 contains some expensive
"assert()" statements in the inner loop of its processing. Setting
the NDEBUG macro makes SQLite 2.0 run nearly twice as fast.
</p>
<p>
All tests are conducted on an otherwise quiescent machine.
A simple shell script generates and runs all the tests.
The shell script is named <a href="speedtest3.sh">speedtest3.sh</a>.
Each test reports three different times:
</p>
<p>
<ol>
<li> "<b>Real</b>" or wall-clock time. </li>
<li> "<b>User</b>" time, the time spent executing user-level code. </li>
<li> "<b>Sys</b>" or system time, the time spent in the operating system. </li>
</ol>
</p>
<p>
PostgreSQL uses a client-server model. The experiment is unable to measure
CPU used by the server, only the client, so the "user" and "sys" numbers
from PostgreSQL are meaningless.
</p>
<h2>Test 1: CREATE TABLE</h2>
<blockquote><pre>
CREATE TABLE t1(f1 int, f2 int, f3 int);
COPY t1 FROM '/home/drh/sqlite/bld/speeddata3.txt';
PostgreSQL: real 1.84
SQLite 1.0: real 3.29 user 0.64 sys 1.60
SQLite 2.0: real 0.77 user 0.51 sys 0.05
</pre></blockquote>
<p>
The speeddata3.txt data file contains 30000 rows of data.
</p>
<h2>Test 2: SELECT</h2>
<blockquote><pre>
SELECT max(f2), min(f3), count(*) FROM t1
WHERE f3<10000 OR f1>=20000;
PostgreSQL: real 1.22
SQLite 1.0: real 0.80 user 0.67 sys 0.12
SQLite 2.0: real 0.65 user 0.60 sys 0.05
</pre></blockquote>
<p>
With no indices, a complete scan of the table must be performed
(all 30000 rows) in order to complete this query.
</p>
<h2>Test 3: CREATE INDEX</h2>
<blockquote><pre>
CREATE INDEX idx1 ON t1(f1);
CREATE INDEX idx2 ON t1(f2,f3);
PostgreSQL: real 2.24
SQLite 1.0: real 5.37 user 1.22 sys 3.10
SQLite 2.0: real 3.71 user 2.31 sys 1.06
</pre></blockquote>
<p>
PostgreSQL is fastest at creating new indices.
Note that SQLite 2.0 is faster than SQLite 1.0 but still
spends longer in user-space code.
</p>
<h2>Test 4: SELECT using an index</h2>
<blockquote><pre>
SELECT max(f2), min(f3), count(*) FROM t1
WHERE f3<10000 OR f1>=20000;
PostgreSQL: real 0.19
SQLite 1.0: real 0.77 user 0.66 sys 0.12
SQLite 2.0: real 0.62 user 0.62 sys 0.01
</pre></blockquote>
<p>
This is the same query as in Test 2, but now there are indices.
Unfortunately, SQLite is reasonably simple-minded about its querying
and not able to take advantage of the indices. It still does a
linear scan of the entire table. PostgreSQL, on the other hand,
is able to use the indices to make its query over six times faster.
</p>
<h2>Test 5: SELECT a single record</h2>
<blockquote><pre>
SELECT f2, f3 FROM t1 WHERE f1==1;
SELECT f2, f3 FROM t1 WHERE f1==2;
SELECT f2, f3 FROM t1 WHERE f1==3;
...
SELECT f2, f3 FROM t1 WHERE f1==998;
SELECT f2, f3 FROM t1 WHERE f1==999;
SELECT f2, f3 FROM t1 WHERE f1==1000;
PostgreSQL: real 0.95
SQLite 1.0: real 15.70 user 0.70 sys 14.41
SQLite 2.0: real 0.20 user 0.15 sys 0.05
</pre></blockquote>
<p>
This test involves 1000 separate SELECT statements, only the first
and last three of which are show above. SQLite 2.0 is the clear
winner. The miserable showing by SQLite 1.0 is due (it is thought)
to the high overhead of executing <b>gdbm_open</b> 2000 times in
quick succession.
</p>
<h2>Test 6: UPDATE</h2>
<blockquote><pre>
UPDATE t1 SET f2=f3, f3=f2
WHERE f1 BETWEEN 15000 AND 20000;
PostgreSQL: real 6.56
SQLite 1.0: real 3.54 user 0.74 sys 1.16
SQLite 2.0: real 2.70 user 0.70 sys 1.25
</pre></blockquote>
<p>
We have no explanation for why PostgreSQL does poorly here.
</p>
<h2>Test 7: INSERT from a SELECT</h2>
<blockquote><pre>
CREATE TABLE t2(f1 int, f2 int);
INSERT INTO t2 SELECT f1, f2 FROM t1 WHERE f3<10000;
PostgreSQL: real 2.05
SQLite 1.0: real 1.80 user 0.81 sys 0.73
SQLite 2.0: real 0.69 user 0.58 sys 0.07
</pre></blockquote>
<h2>Test 8: Many small INSERTs</h2>
<blockquote><pre>
CREATE TABLE t3(f1 int, f2 int, f3 int);
INSERT INTO t3 VALUES(1,1641,1019);
INSERT INTO t3 VALUES(2,984,477);
...
INSERT INTO t3 VALUES(998,1411,1392);
INSERT INTO t3 VALUES(999,1715,526);
INSERT INTO t3 VALUES(1000,1906,1037);
PostgreSQL: real 5.28
SQLite 1.0: real 2.20 user 0.21 sys 0.67
SQLite 2.0: real 10.99 user 0.21 sys 7.02
</pre></blockquote>
<p>
This test involves 1000 separate INSERT statements, only 5 of which
are shown above. SQLite 2.0 does poorly because of its atomic commit
logic. A minimum of two calls to <b>fsync()</b> are required for each
INSERT statement, and that really slows things down. On the other hand,
PostgreSQL also has to support atomic commits and it seems to do so
efficiently.
</p>
<h2>Test 9: Many small INSERTs within a TRANSACTION</h2>
<blockquote><pre>
CREATE TABLE t4(f1 int, f2 int, f3 int);
BEGIN TRANSACTION;
INSERT INTO t4 VALUES(1,440,1084);
...
INSERT INTO t4 VALUES(999,1527,423);
INSERT INTO t4 VALUES(1000,74,1865);
COMMIT;
PostgreSQL: real 0.68
SQLite 1.0: real 1.72 user 0.09 sys 0.55
SQLite 2.0: real 0.10 user 0.08 sys 0.02
</pre></blockquote>
<p>
By putting all the inserts inside a single transaction, there
only needs to be a single atomic commit at the very end. This
allows SQLite 2.0 to go (literally) 100 times faster! PostgreSQL
only gets a eight-fold speedup. Perhaps PostgreSQL is limited here by
the IPC overhead.
</p>
<h2>Test 10: DELETE</h2>
<blockquote><pre>
DELETE FROM t1 WHERE f2 NOT BETWEEN 10000 AND 20000;
PostgreSQL: real 7.25
SQLite 1.0: real 6.98 user 1.66 sys 4.11
SQLite 2.0: real 5.89 user 1.35 sys 3.11
</pre></blockquote>
<p>
All three database run at about the same speed here.
</p>
<h2>Test 11: DROP TABLE</h2>
<blockquote><pre>
BEGIN TRANSACTION;
DROP TABLE t1; DROP TABLE t2;
DROP TABLE t3; DROP TABLE t4;
COMMIT;
PostgreSQL: real 0.06
SQLite 1.0: real 0.03 user 0.00 sys 0.02
SQLite 2.0: real 3.12 user 0.02 sys 0.31
</pre></blockquote>
<p>
SQLite 2.0 is much slower at dropping tables. This may be because
both SQLite 1.0 and PostgreSQL can drop a table simply by unlinking
or renaming a file, since that both use one or more files per table.
SQLite 2.0, on the other hand, uses a single file for the entire
database, so dropping a table involves moving lots of page of that
file to the free-list, which takes time.
</p>
}
puts {
<p><hr /></p>
<p><a href="index.html"><img src="/goback.jpg" border=0 />
Back to the SQLite Home Page</a>
</p>
</body></html>}