> I would expect that sqlite3_prepare would be faster in such a case, and > maybe Toms is pointing out a circumstance where recreating the query > seems to be faster. Or am I misreading the post?
One possible explanation (stab in the dark): If many of the bound parameters are text (or blob) based, and were bound with sqlite3_bind_text(..., SQLITE_TRANSIENT), then SQLite would need to allocate & deallocate memory to hold each bound parameter. (15 params * 384 queries = 5760 allocations.) OTOH, the previous sqlite3_exec approach may have simply sprintf'd the entire SQL statement(s) into a single pre-allocated buffer, possibly avoiding slow-ish dynamic allocations. If the mem allocation time were > than statement compilation time, the "prepare" approach would appear slower. As I said, just a possibility... ~Eric _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
