On 26 May 2009, at 4:56am, Dennis Volodomanov wrote: > Yes, good point... I might compare performance differences in using a > shared connection (multiple threads each opening its own copy of the > database and sharing the connection) vs using the same database from > those threads, unless such timings have already been done?
You would not necessarily get the same results. The way this works would be very sensitive to interactions between the thread scheduling algorithm and the sqlite3 functions, and to how fast the CPUs dealt with sqlite3 functions. One set of timings on processors of a certain speed under a certain OS may not be useful for your particular setup. But this whole thread suggests a little to me that you're engaging in premature optimization: http://en.wikipedia.org/wiki/Optimization_(computer_science)#When_to_optimize You're probably better off ignoring all this stuff and just getting a working solution. Only then is it worth running some sort of profiling system on your application to find out which bits are most worth optimising. Since the sqlite3 library is pretty fast already you might find that fiddling with shared cache defaults could make only 5% the improvement that improving the rest of your code will. Simon. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
