On Fri, Sep 6, 2013 at 11:44 PM, Dominique Devienne <ddevie...@gmail.com>wrote:
> FWIW, I tried to take disk I/O out of the question by using a :memory DB, > and got some weird results of almost instantaneous runs after two initial > runs with similar run time as in the disk db case, and I saw again a 60sec > runtime for the long-name case when other times I'm get 27sec. All in all, > I'm puzzled, but since I have far fewer tables, I'm not too worried despite > my inconclusive experiments. --DD > Silly me. I forgot the final : in :memory:, so I was actually creating a disk DB, and sometimes adding 10K long-named tables to 10K short-named ones, explaining the 27s to 60s jump. With a true memory db, there's a 2x perf difference. Pure conjecture, but perhaps some data structures no longer fit in cache with the 10K long names. Modern CPUs spend most of their time waiting for cache misses, and this could be one example of it. If that's the really the case, the performance decrease should exhibit a "nugget effect" as you increase the table name length, instead of being gradual. But again, that's a wild guess, which I didn't try to verify. --DD [ddevienne@arachne misc]$ gcc sqlite3.c sqlite-many-tables.c -O3 -DNDEBUG -pthread -ldl [ddevienne@arachne misc]$ time ./a.out 10.767u 0.019s 0:10.79 99.8% 0+0k 0+0io 0pf+0w [ddevienne@arachne misc]$ time ./a.out 10.760u 0.018s 0:10.79 99.8% 0+0k 0+0io 0pf+0w [ddevienne@arachne misc]$ time ./a.out 10.767u 0.026s 0:10.79 99.9% 0+0k 0+0io 0pf+0w [ddevienne@arachne misc]$ gcc sqlite3.c sqlite-many-tables.c -O3 -DNDEBUG -pthread -ldl -DLONG_NAMES [ddevienne@arachne misc]$ time ./a.out 20.044s 0:20.90 99.9% 0+0k 0+0io 0pf+0w [ddevienne@arachne misc]$ time ./a.out 20.910u 0.037s 0:20.96 99.9% 0+0k 0+0io 0pf+0w [ddevienne@arachne misc]$ time ./a.out 20.657u 0.049s 0:20.72 99.8% 0+0k 0+0io 0pf+0w _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
