On Wed, Mar 12, 2014 at 5:27 PM, Andreas Stieger <andreas.stie...@gmx.de>wrote:
> Hello, > > I noticed a change in behavior of sqlite3_progress_handler for CREATE > TABLE, or rather the calls to the callbacks, and just wanted to get > clarification if this was intentional. > > Specifically, given the code below for a callback that prints one "." > for each code for this: (full code below) > sqlite3_progress_handler(db, 1, progress_callback, NULL); > sqlite3_exec(db, "create table foo(a,b)", callback, 0, &zErrMsg); > \n > sqlite3_progress_handler(db, 2, progress_callback, NULL); > sqlite3_exec(db, "create table bar(a,b)", callback, 0, &zErrMsg); > > I get the following: > 3.7.17> ./test > .................................................................. > ........................... > 3.8.3.1> ./test > ........ > ....... > 3.8.4> ./test > ..... > ..... > 3.8.4.1> ./test > ..... > ..... > > Is this intentional, a side effect of optimization or unintended > behavior? Documentation does day the callbacks are approximate... > Side-effect of optimization. The progress-callback is now only checked at jump opcodes, not after every opcode, since checking after every opcode uses a measurable fraction of CPU cycles for a feature that is very rarely used. The reduced checking frequency makes not different if you put a reasonable number into the progress callback, like say "100" or "1000". It only shows up with a callback interval of 1 or 2. The second fact is that newer versions of SQLite use fewer VDBE opcodes to accomplish the same task. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
