Documentation Source Text

Check-in [a79b7fc8f1]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Hyperlinks to the faster-than-the-filesystem report from the two application-file-format articles.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: a79b7fc8f107ac078f3ade773f53386ff80f3c7d77702feade8ee154fd640ffb
User & Date: drh 2017-05-12 21:05:27
Context
2017-05-15
17:07
Add the "Why Is SQLite Coded In C" document. check-in: edc057616f user: drh tags: trunk
2017-05-12
21:05
Hyperlinks to the faster-than-the-filesystem report from the two application-file-format articles. check-in: a79b7fc8f1 user: drh tags: trunk
20:17
Mention the anycollseq.c loadable extension in the release notes. check-in: c7eb4e0706 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/aff_short.in.

31
32
33
34
35
36
37
38

39
40
41
42
43
44
45
<li> The application only has to load the data it needs, rather
     than reading the entire file and holding a complete parse
     in memory.
<li> Small edits only overwrite the parts of the file that change,
     reducing write time and wear on SSD drives.
<li> In many cases, loading content from an SQLite database
     is faster than reading individual files from disk.
     See [Internal Versus External BLOBs].

</ul>
<li><b>Reduced application cost and complexity</b>
<ul>
<li> No application file I/O code to write and debug.
<li> Content can be accessed and updated using concise SQL queries instead
     of lengthy and error-prone procedural routines.
<li> The file format can be extended in future releases simply







|
>







31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
<li> The application only has to load the data it needs, rather
     than reading the entire file and holding a complete parse
     in memory.
<li> Small edits only overwrite the parts of the file that change,
     reducing write time and wear on SSD drives.
<li> In many cases, loading content from an SQLite database
     is faster than reading individual files from disk.
     See [Internal Versus External BLOBs] and
     [faster than the filesystem|35% Faster Than The Filesystem].
</ul>
<li><b>Reduced application cost and complexity</b>
<ul>
<li> No application file I/O code to write and debug.
<li> Content can be accessed and updated using concise SQL queries instead
     of lengthy and error-prone procedural routines.
<li> The file format can be extended in future releases simply

Changes to pages/appfileformat.in.

327
328
329
330
331
332
333


334
335
336
337
338
339
340
341
342
prior screens that is no longer in use.  This helps keep the memory
footprint of the application under control.

<p>A pile-of-files format can be read incrementally just like SQLite.
But many developers are surprised to learn that SQLite can read and 
write smaller BLOBs (less than about 100KB in size) from its database 
faster than those same blobs can be read or written as separate files 


from the filesystem.  (See [Internal Versus External BLOBs] for further 
information.)  There is overhead associated with operating a relational
database engine, however one should not assume that direct file I/O
is faster than SQLite database I/O, as often it is not.

<p>In either case, if performance problems do arise in an SQLite application 
those problems can often be resolved by adding one or two [CREATE INDEX]
statements to the schema or perhaps running [ANALYZE] one time
and without having to touch a single line of







>
>
|
|







327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
prior screens that is no longer in use.  This helps keep the memory
footprint of the application under control.

<p>A pile-of-files format can be read incrementally just like SQLite.
But many developers are surprised to learn that SQLite can read and 
write smaller BLOBs (less than about 100KB in size) from its database 
faster than those same blobs can be read or written as separate files 
from the filesystem.  (See
[faster than the filesystem|35% Faster Than The Filesystem] and
[Internal Versus External BLOBs] for further information.)
There is overhead associated with operating a relational
database engine, however one should not assume that direct file I/O
is faster than SQLite database I/O, as often it is not.

<p>In either case, if performance problems do arise in an SQLite application 
those problems can often be resolved by adding one or two [CREATE INDEX]
statements to the schema or perhaps running [ANALYZE] one time
and without having to touch a single line of