On 06/01/11 20:30, Sylvain Pointeau wrote: > I did the benchmark, > > I created a table with 5 columns: A,B,C,D,E A,B,C are REAL D,E are > INTEGER > > to retrieve 10000 rows: -using sqlite3 api, total time for 10 loops: > 0.194569 seconds -using soci, total time for 10 loops: 0.79895 > seconds
Compiled with -O3 mlos...@dog:~/dev/soci/test/sylvain_benchmark$ ./sylvain_benchmark sum A : 4982.25 sum A : 4982.25 using sqlite3 api, total time for 10loops: 0.1 seconds using soci, total time for 10loops: 0.43 seconds > What are your thoughts? SOCI is 4x slower than "naked" SQLite3 API. SOCI is not expected to be faster nor to be even as fast as low-level database API. Simply, SOCI does much more than SQLite3 API, there is overhead. The benchmark itself does not point any particular place of bottleneck. However, if a profiler is used, we can see some interesting figures. Here are the benchmark files http://mateusz.loskot.net/tmp/soci/sylvain_benchmark/ The two most important are: - sylvain_benchmark_callgrind.out - output generated by valgrind/callgrind, so everyone who wants can visualise the profiling results in kcachegrind - sylvain_benchmark_callgrind_graph.png - graph summarising cost of significant functions. I don't have time at this moment to dive into deep interpretation, but basically two places are interesting. 1. Subtree with root in statement_impl::post_fetch which leads to sqlite3::string_to_integer taking 10% of execution time Perhaps this could be optimised 2. Subtree with root in sqlite3_statement_backend::load_rowset and its branch to sqlite3_column_text which takes 25% of time Conclusion from this 5 minutes simple investigation is that sqlite3_value_text calls seem to be expansive, so it may be worth to use type-specific API in SQLite3 backend. If you (or anyone) else would be willing to give it a try, it would be awesome and further tests will be very interesting. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
