On Wed, Mar 12, 2014 at 5:27 PM, Andreas Stieger 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