Most of that looks to be more like common sense things rather than SQLite specific, so why they're calling out SQLite, I've no idea. Also, this doc was last modified more than a year ago. Stuff has changed both within FF as well as SQlite since then.
I've just deleted the blog I was going to write here, since I know I'm pissing people off with my long thoughts (And I'm tired), so yeah... I'll cut it to a paragraph. *Old data, common sense to clean up sometime during the current apps life cycle, or something completely different spawned after the primary apps life cycle with low priority. *Proper knowledge of how SQLite handles indexing of data is required (Looked at that bug report linked). *Fragmentation happens, within and outside databases. *Database page sizes should be close to your "common" target platforms disk cluster size to reduce disk IO. *And yeah... I LOL'd at "JSON files or log files will show better I/O patterns almost every time, especially if they're compressed and read/written in entirety each time", specifically at JSON, and the concept that substituting disk IO for CPU time to decompress then ANALYZE the full content of that data, then delete previous data to recompress data is any better, ESPECIALLY when trickling data into a compressed JSON log file. Not a fan of that JSON fanboi tech at all. On Sun, Jun 14, 2015 at 9:08 AM, Jean Chevalier <jchevalier at gmx.net> wrote: > Somewhat contradictory the Mozilla Foundation being a member of the SQLite > Consortium while their performance wiki prominently features a warning to > developers against using SQLite allegedly for performance reasons. Guard me > from my friends... > > > http://wiki.mozilla.org/Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
