Small. Fast. Reliable.
Choose any three.
Choose any three.
SQLite库使用的代码空间取决于目标平台，编译器和优化设置。这些变量也会影响性能。
下表显示了截至2017年10月8日SQLite的相对大小和性能，这些性能是在x86_64上的Ubuntu 16.04.3上测试的各种编译器和优化设置的。一般观察：
Clang / LLVM编译器与GCC没有竞争力。Clang生成的二进制文件始终比GCC生成的二进制文件大和慢。
配置文件引导的优化（PGO）对SQLite无效。PGO生成的二进制文件大约大1％，而速度慢0.33％。
GCC-7生成的二进制文件比GCC-5小和快，尽管差别并不大。
使用GCC和-Os进行编译会导致二进制文件的大小略小于500KB。（更新2018-07-07：由于增加了UPSERT和窗口功能等新功能，库的占用空间现在略大于500KB。）
开发人员需要做出的唯一重要的设计决策是使用-O（针对大小进行优化）还是-O6（针对速度进行优化）。-O6设置可使二进制文件的运行速度提高约2％或3％，但也大66％。这里的性能是通过使用cachegrind计数CPU周期来衡量的。分析中不考虑I高速缓存未命中。如果考虑了I高速缓存未命中，那么使用-O6进行构建可能不会比使用-Os进行构建更快。
考虑到上述所有因素，SQLite开发人员建议使用带有-Os优化设置的GCC-7来编译SQLite。
以上测量是使用2017年10月8日的SQLite版本5594a121bf132a98进行的 。
使用的唯一SQLite编译时选项是-DSQLITE_ENABLE_MEMSYS5。可选的memsys5内存分配器用于性能测试，因为它提供的结果比Ubuntu上库提供的malloc（）/ free（）更具可重复性。
性能可以提高，尺寸通过使减小-DSQLITE_THREADSAFE = 0， -DSQLITE_DEFAULT_MEMSTATUS = 0， -DSQLITE_DEFAULT_WAL_SYNCHRONOUS = 1， -DSQLITE_LIKE_DOESNT_MATCH_BLOBS， -DSQLITE_MAX_EXPR_DEPTH = 0， -DSQLITE_OMIT_DECLTYPE， -DSQLITE_OMIT_DEPRECATED， -DSQLITE_OMIT_PROGRESS_CALLBACK， -DSQLITE_OMIT_SHARED_CACHE，和 -DSQLITE_USE_ALLOCA。所有这些选项共同导致大约3.5％的性能提高和3.0％的尺寸减小。
添加可选功能-DSQLITE_ENABLE_JSON1， -DSQLITE_ENABLE_FTS5或-DSQLITE_ENABLE_RTREE显然会增加库的大小。
使用speedtest1.c实用程序测量了性能 ，该实用程序试图模仿SQLite的典型工作负载。测试运行的选项有：
--shrink-memory --reprepare --stats --heap 10000000 64 --size 5通过使用cachegrind运行speedtest1并观察“ I refs”输出来测量性能。