Documentation Source Text

<ol>
<li><p><b>[SQLITE_DQS=0]</b>.
This setting disables the [double-quoted string literal] misfeature.

<li><p><b>[SQLITE_THREADSAFE=0]</b>.
Setting -DSQLITE_THREADSAFE=0 causes all of the mutex and thread-safety logic
in SQLite to be omitted.  This is the single compile-time option that makes
the most difference in optimizing the performance of SQLite.




<li><p><b>[SQLITE_DEFAULT_MEMSTATUS=0]</b>.
This setting causes the [sqlite3_status()] interfaces that track memory usage
to be disabled.  This helps the [sqlite3_malloc()] routines run much faster,
and since SQLite uses [sqlite3_malloc()] internally, this helps to make the
entire library faster.

................................................................................
in performance-critical sections of the code to be eliminated.  This can
give a noticeable improvement in performance.

<li><p><b>[SQLITE_USE_ALLOCA]</b>.
Make use of alloca() for dynamically allocating temporary stack space for 
use within a single function, on systems that support alloca().  Without
this option, temporary space is allocated from the heap.














</ol>

<p>When all of the recommended compile-time options above are used,
the SQLite library will be approximately 3% smaller and use about 5% fewer
CPU cycles.  So these options do not make a huge difference.  But in 
some design situations, every little bit helps.

<ol>
<li><p><b>[SQLITE_DQS=0]</b>.
This setting disables the [double-quoted string literal] misfeature.

<li><p><b>[SQLITE_THREADSAFE=0]</b>.
Setting -DSQLITE_THREADSAFE=0 causes all of the mutex and thread-safety logic
in SQLite to be omitted.  This is the single compile-time option causes SQLite
to run about 2% faster and also reduces the size of the library by about 2%.
But the downside is that using the compile-time option means that SQLite can never
be used by more than a single thread at a time, even if each thread has its own
database connection.

<li><p><b>[SQLITE_DEFAULT_MEMSTATUS=0]</b>.
This setting causes the [sqlite3_status()] interfaces that track memory usage
to be disabled.  This helps the [sqlite3_malloc()] routines run much faster,
and since SQLite uses [sqlite3_malloc()] internally, this helps to make the
entire library faster.

................................................................................
in performance-critical sections of the code to be eliminated.  This can
give a noticeable improvement in performance.

<li><p><b>[SQLITE_USE_ALLOCA]</b>.
Make use of alloca() for dynamically allocating temporary stack space for 
use within a single function, on systems that support alloca().  Without
this option, temporary space is allocated from the heap.

<li><p><b>[SQLITE_OMIT_AUTOINIT]</b>.
The SQLite library needs to be initialized using a call to
[sqlite3_initialize()] before certain interfaces are used.  
This initialization normally happens automatically the first time
it is needed.  However, with the SQLITE_OMIT_AUTOINIT option, the automatic
initialization is omitted.  This helps many API calls to run a little faster
(since they do not have to check to see if initialization has already occurred
and then run initialization if it has not previously been invoked) but it
also means that the application must call [sqlite3_initialize()] manually.
If SQLite is compiled with -DSQLITE_OMIT_AUTOINIT and a routine like
[sqlite3_malloc()] or [sqlite3_vfs_find()] or [sqlite3_open()] is invoked
without first calling [sqlite3_initialize()], the likely result will be
a segfault.
</ol>

<p>When all of the recommended compile-time options above are used,
the SQLite library will be approximately 3% smaller and use about 5% fewer
CPU cycles.  So these options do not make a huge difference.  But in 
some design situations, every little bit helps.