On Wed, Jun 15, 2016 at 08:46:37AM +0200, Marc Kleine-Budde wrote: > On 06/15/2016 07:08 AM, Michael Olbrich wrote: > > On Wed, Jun 15, 2016 at 12:21:19AM +0200, Clemens Gruber wrote: > >> - Bump the version to 3.13.0: http://sqlite.org/releaselog/3_13_0.html > >> - Using FTS4 also enables FTS3, they share most of their code and FTS4 > >> is recommended for new applications. (Better query performance) > >> - Include the JSON1 functions > >> - The lookaside memory allocator should not be disabled, it is the > >> default allocator since 3.6.1 and is much quicker. 50KB per database > >> connection are used for the memory pool but this can be changed at > >> runtime, if a smaller memory footprint is required. > >> - SECURE_DELETE should not be the default, those who need it can always > >> enable it at runtime with the secure_delete pragma. That build option > >> only controls the default value. > > > > Marc, you introduced these options. Can you comment? > > Sorry, I don't remember why I switched on these options.
Maybe it was a usecase with extremely low memory footprint and security critical data stored in the database? Or the lookaside allocator was deemed too new and not stable enough back then. Today, I see no reason to disable the lookaside allocator. It causes less latency and is only a little heavier on memory. Also if the slots are full or for larger allocations, SQLite falls back to malloc anyway. Secure delete has a significant performance penalty. Users can always opt-in with PRAGMA secure_delete = 1; if they need to zero out deleted content. Also, due to the limited number of erase cycles on flash storage, I would rather encrypt the data than zero it out. (SQLCipher extension!) Then I'd only have to throw away the key. Clemens _______________________________________________ ptxdist mailing list [email protected]
