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. |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
a79b7fc8f107ac078f3ade773f53386f |
| 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
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 |