Richard Hipp-3 wrote > From the description, your tests sound like you are pushing a bunch of > separate SQL statements into SQLite. In other words, the compute time > is likely dominated by the time need to parse the SQL and prepare > plans.
Yes > Have you rerun the tests using prepared statements, where you > do a limited number of sqlite3_prepare_v2() calls and then reuse each > prepared statement multiple times with different bound parameters? > That's the kind of work-load we have been striving to optimize, since > we figure anybody who is interested in performance is already making > heavy use of prepared statements. We call SQLite from C# and use a .net wrapper inspired by system.data.sqlite package. In other words there is a lot of overhead in high level layer. (Moreover, we rely on Mono implementation, which is even slower.) In the old days I run a lot of tests trying to find out the fastest way until we decided for the current algorithm. Since then we heavily optimized the C# layer and you now optimized the C code. Maybe the original decision is not true anymore. If I find spare time I'll run the tests again. But right now I am primarily interested whether it makes sense to upgrade SQLite code. -- View this message in context: http://sqlite.1065341.n5.nabble.com/Performance-increase-between-3-7-and-3-8-tp80355p80367.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
