Trying out `zig cc` as a CGO compiler for embedded sqlite. So far it's a good amount slower.
First up, sqlite isn't using the intrinsics because of its preprocessor logic. Ok, fix that, some gap closed.
Next apply march=haswell, often need a march w/ clang.
Still 10+% to go..
Conversation
Replying to
SQLite gets an easy performance win from disabling certain deprecated/optional functionality.
-DSQLITE_DQS=0
-DSQLITE_LIKE_DOESNT_MATCH_BLOBS
-DSQLITE_OMIT_DEPRECATED
-DSQLITE_DEFAULT_MEMSTATUS=0
-DSQLITE_OMIT_DECLTYPE
-DSQLITE_OMIT_PROGRESS_CALLBACK
-DSQLITE_OMIT_SHARED_CACHE
1
They also intend for people to use -DSQLITE_USE_ALLOCA although alloca/VLAs aren't always available. If you can guarantee sqlite3_initialize is called before anything else you can use -DSQLITE_OMIT_AUTOINIT too. There are further performance wins from things with a safety cost.
1
They recommend compiling without thread safety but that's very impractical. It's usually compiled with -DSQLITE_THREADSAFE=1 (full thread safety) but libraries for other languages can be designed so that -DSQLITE_THREADSAFE=2 is safe to remove locking on connections / statements.
For example, there's no reason you would need -DSQLITE_THREADSAFE=1 for Rust when you can already make sure nothing accesses connections / statements concurrently simply by using normal library design. That will get a lot more performance out of it than most micro-optimizations.
1
-DSQLITE_MAX_EXPR_DEPTH=0 too if you don't care about malicious / contrived SQL being able to overflow the stack.
They also recommend -DSQLITE_DEFAULT_WAL_SYNCHRONOUS=1 if you can tolerate OS crashes / power loss rolling back to last WAL checkpoint.
sqlite.org/pragma.html#pr
2