06-01-2016, Scott Perry: The SQLite built into OS X does not support cache sharing for performance reasons?, which is probably why your results are statistically identical and the OP's results are wildly different.
You can verify this by checking the return value of sqlite3_enable_shared_cache; on OS X it returns SQLITE_MISUSE. - On multicore systems, memory barriers are extremely expensive; not sharing caches allows them to run lock-free Hello, to recall the timings once again: sanhua.zh's test (objective C) without shared cache mode 2015-12-20 21:28:49.647 Test[1286:13077] cost 0.028914 2015-12-20 21:28:49.647 Test[1286:13078] cost 0.028914 2015-12-20 21:28:49.647 Test[1286:13079] cost 0.028964 2015-12-20 21:28:49.647 Test[1286:13076] cost 0.028958 shared cache mode 2015-12-20 21:24:58.714 Test[1126:11609] cost 2.173480 2015-12-20 21:24:58.714 Test[1126:11610] cost 2.173449 2015-12-20 21:24:58.714 Test[1126:11608] cost 2.173768 2015-12-20 21:24:58.714 Test[1126:11611] cost 2.173169 My Python test: Timings for default mode: steps 100000 connect+fetch 4.39 connect 0.0 steps 100000 connect+fetch 4.52 connect 0.0 steps 100000 connect+fetch 4.62 connect 0.0 steps 100000 connect+fetch 4.51 connect 0.0 elapsed 5.21 Timings in shared cache mode: steps 100000 connect+fetch 6.4 connect 0.0 steps 100000 connect+fetch 6.17 connect 0.0 steps 100000 connect+fetch 6.56 connect 0.0 steps 100000 connect+fetch 6.46 connect 0.0 elapsed 6.85 At least the tests in non-shared cache mode should be comparable. And I try to explain why on my poor Mac the test is 100-200 times slower there (4.5 / 0.03 seconds). This must be the overhead of the Python wrapper. After sqlite_step the row is converted for Python. This overhead is practically neglectable but apparently not in an exagerated test (fetching rows without any further action). Further it would be interesting to know if Sanhua tested on a multicore system. Then cache sharing is indeed very expensive there (if I summarize this correctly) Thanks, E. Pasma
