Documentation Source Text

Check-in [f250d55692]
Login

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

Overview
Comment:Add the SQLITE_OMIT_AUTOINIT compile-time option to the set of recommended compile-time options.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: f250d5569221a3746467a94379e2008f48641c972b446189b42a89113dfb676d
User & Date: drh 2020-01-29 21:29:53
Context
2020-01-29
23:04
Enhancements to the FTS3/4 documentation about the limitations of BOMs in string literals with the simple tokenizer in a UTF16 database. check-in: 4d11f30804 user: drh tags: trunk
21:29
Add the SQLITE_OMIT_AUTOINIT compile-time option to the set of recommended compile-time options. check-in: f250d55692 user: drh tags: trunk
20:19
Document the byte-order-mark limitation of fts3/4. check-in: 7e55864b0a user: dan tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/compile.in.

58
59
60
61
62
63
64
65
66



67
68
69
70
71
72
73
...
117
118
119
120
121
122
123














124
125
126
127
128
129
130

<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.








|
|
>
>
>







 







>
>
>
>
>
>
>
>
>
>
>
>
>
>







58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
...
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147

<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.