Re: [sqlite] Big difference in performance between Python and gcc

2011-06-06 Thread Alessandro Marzocchi 
2011/6/1 Dominique Pellé :
> Alessandro Marzocchi wrote:
>
>> Hello,
>>    I made some preliminary tests for an application storing big
>> chunks of data in a sqlite database. I did firsts tests with python
>> and they gave me quite impressive results. I then tried to make the
>> same test using C. I expected to get execution times to be the same of
>> those of python. However I was surprised as the performance got a lot
>> worse, with execution times being more than 3 times more.
>
> ...snip...
>
>>  if(SQLITE_OK!=(ret=sqlite3_prepare_v2(db,
>>    "INSERT INTO helloworld VALUES (?,?,?)",
>>    -1,
>>    _stm,
>>    NULL
>>  )))
>
> Since you're going to always insert 1 in the first
> column, why not use:
>
> INSERT INTO helloworld VALUES (1,?,?)
>
>
>>  {
>>    fprintf(stderr,"sqlite error in prepare() [%d]",ret);
>>    return -1;
>>  };
>>
>>  int i;
>>  char data[1024*8+1];
>>  for(i=0;i<1024*8;i++)data[i]='0';
>>  data[1024*8]='\0';
>
> Since the data column also does not change,
> you could bind it only once before entering
> the for loop (rather than binding it at each loop
> iteration)
>
>
>>  for(i=0;i<10;i++)
>>  {
>>    if(!(i%1))printf("%d\n",i);
>>
>>    if(SQLITE_OK!=(ret=sqlite3_bind_int(db_stm, 1, 1)))
>>    {
>>      fprintf(stderr,"sqlite error in bind()");
>>      return -1;
>>    }
>
> Above bind is useless if you used:
> INSERT INTO helloworld VALUES (1,?,?)
>
>
>>    if(SQLITE_OK!=(ret=sqlite3_bind_int(db_stm, 2, i)))
>>    {
>>      fprintf(stderr,"sqlite error in bind()");
>>      return -1;
>>    }
>>    //if(SQLITE_OK!=(ret=sqlite3_bind_blob(db_stm, 3, data,-1,
>> SQLITE_STATIC/*SQLITE_TRANSIENT*/)))
>>    if(SQLITE_OK!=(ret=sqlite3_bind_blob(db_stm, 3, data,8192,
>> SQLITE_STATIC/*SQLITE_TRANSIENT*/)))
>>    {
>>      fprintf(stderr,"sqlite error in bind_blob() [%d] ok=%d",ret,SQLITE_OK);
>>      return -1;
>>    }
>
> above bind to blob can be moved outside the loop.
>
>
>>    ret=sqlite3_step(db_stm);
>>    if(ret!=SQLITE_DONE)
>>    {
>>      fprintf(stderr,"sqlite error in sqlite3_step() [%d]",ret);
>>      return -1;
>>    }
>>    if(SQLITE_OK!=(ret=sqlite3_reset(db_stm)))
>>    {
>>      fprintf(stderr,"sqlite error in sqlite3_reset() [%d]",ret);
>>      return -1;
>>    }
>>    sqlite3_clear_bindings(db_stm);
>
> Calling sqlite3_clear_binding(...) at each iteration
> is not needed in your example.  In fact, you should
> not call it at all if you decide to move the bind to the blob
> outside the loop.
>
> That should make it faster.
I used this structure as it is more representative of what the queries
the real application will do...
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Big difference in performance between Python and gcc

2011-06-06 Thread Alessandro Marzocchi 
On the weekend I had way to test the same code on a linux box...
performance there are as expected (with C performing slightly better
than python with a ~20% difference in execution times between the
two). I'll try disabling thread, as they could give a big performance
hit on win system.


2011/6/3 Roger Binns :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/02/2011 02:17 PM, Simon Slavin wrote:
>>  Do you understand the strange result the OP reported ?
>
> There is no evidence that Python is any way relevant to this issue and the
> OP appears to have gone silent.  I expect the actual cause is how SQLite was
> compiled.  Both Python wrappers include the amalgamation statically within
> the extension (ie there is no DLL or dynamic linking involved) on Windows.
>
> Edzard also showed how much faster my wrapper is that the standard Python
> one.  I aim to please :)  The other differences are documented here:
>
>  http://apidoc.apsw.googlecode.com/hg/pysqlite.html
>
> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk3oSPUACgkQmOOfHg372QRwxgCgjW9Y4X52DSe9XqUWiOfTkqO1
> tPsAn3sry8hFbioD6mHOXsCfWfJIo3XM
> =KIcg
> -END PGP SIGNATURE-
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Big difference in performance between Python and gcc

2011-06-02 Thread Roger Binns 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/02/2011 02:17 PM, Simon Slavin wrote:
>  Do you understand the strange result the OP reported ?

There is no evidence that Python is any way relevant to this issue and the
OP appears to have gone silent.  I expect the actual cause is how SQLite was
compiled.  Both Python wrappers include the amalgamation statically within
the extension (ie there is no DLL or dynamic linking involved) on Windows.

Edzard also showed how much faster my wrapper is that the standard Python
one.  I aim to please :)  The other differences are documented here:

  http://apidoc.apsw.googlecode.com/hg/pysqlite.html

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3oSPUACgkQmOOfHg372QRwxgCgjW9Y4X52DSe9XqUWiOfTkqO1
tPsAn3sry8hFbioD6mHOXsCfWfJIo3XM
=KIcg
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Big difference in performance between Python and gcc

2011-06-02 Thread Edzard Pasma 
Op 2-jun-2011, om 23:17 heeft Simon Slavin het volgende geschreven:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On 2 Jun 2011, at 7:24pm, Roger Binns wrote:
>
>> (Incidentally I am the author of a "competing" Python SQLite  
>> binding and
>> hence know exactly which SQLite API calls result from bits of  
>> Python hence
>> being very pedantic about getting these tests the same.)
>
> How does your own Python binding perform ?  Is it fast like the  
> other Python binding, or slow like the GCC-compiled C code the OP  
> reported ?  Do you understand the strange result the OP reported ?
>
> Simon.

If I may answer the first question: APSW is even 31.7 % faster than  
the default Python wrapper, using the version below. It is however  
relevant to drop the table before each new test run. (I changed  
'create if not exists' to 'drop if exists' in both tests).

import apsw
import timeit
conn = apsw.Connection('test1.sqlite')
c=conn.cursor()
c.execute('''DROP TABLE IF EXISTS values_log; CREATE TABLE values_log 
(acquisition
INTEGER,chunk INTEGER, acq_data BLOB);
  CREATE INDEX IF NOT EXISTS values_step ON
values_log(acquisition,chunk);
   ''' )

def f():
   data="01234567"*1024
   with conn:
 for i in range(0,1):
   conn.cursor ().execute("INSERT INTO values_log VALUES (?,?,?)", 
(1,i,data))
   if not i%1: print i
ret=timeit.timeit(f,'gc.enable()',number=1)
print ret


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Big difference in performance between Python and gcc

2011-06-02 Thread Simon Slavin 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 2 Jun 2011, at 7:24pm, Roger Binns wrote:

> (Incidentally I am the author of a "competing" Python SQLite binding and
> hence know exactly which SQLite API calls result from bits of Python hence
> being very pedantic about getting these tests the same.)

How does your own Python binding perform ?  Is it fast like the other Python 
binding, or slow like the GCC-compiled C code the OP reported ?  Do you 
understand the strange result the OP reported ?

Simon.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJN5/3qAAoJEIgFUSuEK6DjU8kH/Rp9s0Pa50UZE7o2eTgnkJCA
PTMDw0gavFgscxqgnUXdeKWKWuu3Q4iqbt4HFKfNthF3ozbtZjnCzFCWPinTM9KF
DgU9oyqfScutWSPdQKQcl/JhkGlvQ3zaB4QUI/PN8/+b+6K8h1uIr8CLCktVh6Kt
1hc3GXSyDJnyRv2pv7yn1t0aDdFvGM1L+mBF+anWQu5LlUZVL6xfD8rtSKNyFQYW
lYz1gE+RElGarzpF2UoOp5M4xhomTcfBA0B+6spQ0M68r2eXzkq1baq1gbJKgzeI
OkLvpt++HCXrLb4JtKfsS6OH20384RvMFu/yPjAuCUQUr75DAaMFZ7yOCBUOSsM=
=RBhc
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Big difference in performance between Python and gcc

2011-06-02 Thread Roger Binns 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/02/2011 04:38 AM, Simon Slavin wrote:
> Python is a bytecode language.  

That isn't relevant in this case.  The code that interfaces Python to SQLite
is written in C.  The amount of Python bytecode involved in this benchmark
is irrelevant.

On 06/02/2011 12:55 AM, Dominique Pellé wrote:
> However, for a benchmark, it's best to avoid things that
> can be trivially optimized.  I don't know how the python
> code translates into SQLite C API.

In this particular case the OP is unable to modify the Python SQLite binding
and what is trying to be established is why the performance differs, not the
optimum sequences of code.  That is why it is important to make sure that
they are measuring exactly the same thing before investigating the massive
difference in run times.

(Incidentally I am the author of a "competing" Python SQLite binding and
hence know exactly which SQLite API calls result from bits of Python hence
being very pedantic about getting these tests the same.)

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3n1XEACgkQmOOfHg372QTINACgsnRCkY6k6FQJQ0zOjHQUcCxj
ryEAnj+2dk8eUYtbImaEfwXAWSQzlyyU
=TTPX
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Big difference in performance between Python and gcc

2011-06-02 Thread Simon Slavin 

On 2 Jun 2011, at 8:55am, Dominique Pellé wrote:

> Roger Binns wrote:
> 
>> While those are all valid, they don't address the underlying issue which is
>> C code taking five times longer than Python code for the same SQLite
>> operations.  In addition that same "redundant" code is executed behind the
>> scenes in Python so it is fair for these comparisons/benchmark.
>> 
>> Other things having been ruled out, it looks like Jan's suggestion of
>> compilation options and code is likely the cause.

One does normally assume that C code is going to be pretty efficient.  I was 
surprised at the OP's information.

> That's true of course and I should have mentioned it.
> However, for a benchmark, it's best to avoid things that
> can be trivially optimized.  I don't know how the python
> code translates into SQLite C API.

Python is a bytecode language.  Current compilers (the bit that /makes/ the 
bytecodes, not the bit that reads them) are very good at trimming off code 
which leads to results which are never used.  Which, as commented above, makes 
it extremely difficult to write benchmark programs in Python.

Simon.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Big difference in performance between Python and gcc

2011-06-02 Thread Dominique Pellé 
Roger Binns wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/01/2011 12:25 PM, Dominique Pellé wrote:
>> [Various optimisations]
>
> While those are all valid, they don't address the underlying issue which is
> C code taking five times longer than Python code for the same SQLite
> operations.  In addition that same "redundant" code is executed behind the
> scenes in Python so it is fair for these comparisons/benchmark.
>
> Other things having been ruled out, it looks like Jan's suggestion of
> compilation options and code is likely the cause.
>
> Roger

That's true of course and I should have mentioned it.
However, for a benchmark, it's best to avoid things that
can be trivially optimized.  I don't know how the python
code translates into SQLite C API.

-- Dominique
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Big difference in performance between Python and gcc

2011-06-01 Thread Roger Binns 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/01/2011 12:25 PM, Dominique Pellé wrote:
> [Various optimisations]

While those are all valid, they don't address the underlying issue which is
C code taking five times longer than Python code for the same SQLite
operations.  In addition that same "redundant" code is executed behind the
scenes in Python so it is fair for these comparisons/benchmark.

Other things having been ruled out, it looks like Jan's suggestion of
compilation options and code is likely the cause.

Roger

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3ml7MACgkQmOOfHg372QRuoQCfcKEV8YauTG2BB2a3ux1XqSVi
9HIAoIZtc/qP4p+kJxrv1Av+DlFg7T2n
=BHQY
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Big difference in performance between Python and gcc

2011-06-01 Thread Dominique Pellé 
Alessandro Marzocchi wrote:

> Hello,
>    I made some preliminary tests for an application storing big
> chunks of data in a sqlite database. I did firsts tests with python
> and they gave me quite impressive results. I then tried to make the
> same test using C. I expected to get execution times to be the same of
> those of python. However I was surprised as the performance got a lot
> worse, with execution times being more than 3 times more.

...snip...

>  if(SQLITE_OK!=(ret=sqlite3_prepare_v2(db,
>    "INSERT INTO helloworld VALUES (?,?,?)",
>    -1,
>    _stm,
>    NULL
>  )))

Since you're going to always insert 1 in the first
column, why not use:

INSERT INTO helloworld VALUES (1,?,?)


>  {
>    fprintf(stderr,"sqlite error in prepare() [%d]",ret);
>    return -1;
>  };
>
>  int i;
>  char data[1024*8+1];
>  for(i=0;i<1024*8;i++)data[i]='0';
>  data[1024*8]='\0';

Since the data column also does not change,
you could bind it only once before entering
the for loop (rather than binding it at each loop
iteration)


>  for(i=0;i<10;i++)
>  {
>    if(!(i%1))printf("%d\n",i);
>
>    if(SQLITE_OK!=(ret=sqlite3_bind_int(db_stm, 1, 1)))
>    {
>      fprintf(stderr,"sqlite error in bind()");
>      return -1;
>    }

Above bind is useless if you used:
INSERT INTO helloworld VALUES (1,?,?)


>    if(SQLITE_OK!=(ret=sqlite3_bind_int(db_stm, 2, i)))
>    {
>      fprintf(stderr,"sqlite error in bind()");
>      return -1;
>    }
>    //if(SQLITE_OK!=(ret=sqlite3_bind_blob(db_stm, 3, data,-1,
> SQLITE_STATIC/*SQLITE_TRANSIENT*/)))
>    if(SQLITE_OK!=(ret=sqlite3_bind_blob(db_stm, 3, data,8192,
> SQLITE_STATIC/*SQLITE_TRANSIENT*/)))
>    {
>      fprintf(stderr,"sqlite error in bind_blob() [%d] ok=%d",ret,SQLITE_OK);
>      return -1;
>    }

above bind to blob can be moved outside the loop.


>    ret=sqlite3_step(db_stm);
>    if(ret!=SQLITE_DONE)
>    {
>      fprintf(stderr,"sqlite error in sqlite3_step() [%d]",ret);
>      return -1;
>    }
>    if(SQLITE_OK!=(ret=sqlite3_reset(db_stm)))
>    {
>      fprintf(stderr,"sqlite error in sqlite3_reset() [%d]",ret);
>      return -1;
>    }
>    sqlite3_clear_bindings(db_stm);

Calling sqlite3_clear_binding(...) at each iteration
is not needed in your example.  In fact, you should
not call it at all if you decide to move the bind to the blob
outside the loop.

That should make it faster.

-- Dominique
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Big difference in performance between Python and gcc

2011-06-01 Thread Jan Hudec 
On Wed, Jun 01, 2011 at 09:25:04 +0200, Alessandro Marzocchi wrote:
> However I was surprised as the performance got a lot
> worse, with execution times being more than 3 times more. I tried
> everything I could think of and also peeked at python module's source
> but i couldn't find any way to get C program performance to match
> python's one.

Are you linking against existing sqlite library or compiling it yourself?i

If the later, make sure you enabled all optimizations and disabled assertions
in sqlite. Your flags when compiling sqlite source should include -O3 (most
optimizations) and -DNDEBUG (to turn off assertions). These tend to make huge
effect on sqlite performance.

-- 
 Jan 'Bulb' Hudec 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Big difference in performance between Python and gcc

2011-06-01 Thread Alessandro Marzocchi 
Hi Roger,
  thank for your answer. I tried to modify programs to match your
suggestion, performances improved but are still far from pyhon's ones.
(Sorry if this message starts a different thread but i had forwards of
single messages disabled so i could not reply to the original post)

 C modified source and timing -
bash-3.1$ diff test.c testold.c
9c9
<   sqlite3_open("test1.sqlite", );
---
>   sqlite3_open("testDB.sql", );
45c45
<   for(i=0;i<1024*8;i++)data[i]='0'+i%10;
---
>   for(i=0;i<1024*8;i++)data[i]='0';
61c61
< if(SQLITE_OK!=(ret=sqlite3_bind_text(db_stm, 3, data,-1,
---
> //if(SQLITE_OK!=(ret=sqlite3_bind_text(db_stm, 3, data,-1,
63c63
< //if(SQLITE_OK!=(ret=sqlite3_bind_blob(db_stm, 3, data,8192,
---
> if(SQLITE_OK!=(ret=sqlite3_bind_blob(db_stm, 3, data,8192,


bash-3.1$ gcc -O2 test.c sqlite/sqlite3.c && time ./a.exe
[...]

real1m58.056s
user0m0.015s
sys 0m0.015s

 Python's timing (another run, i'm looking at time tool statistic
not at timeit module so they include also startup times)
bash-3.1$ time python testsqlite.py
[...]

real0m30.906s
user0m0.015s
sys 0m0.000s

 Trying the other way round (making python's code same as old C code)
bash-3.1$ diff testsqlite.py testsqlite_old.py
12c12
< conn = sqlite3.connect('testDB.sql')
---
> conn = sqlite3.connect('test1.sqlite')
51c51
<   data=buffer(""*1024)
---
>   data="01234567"*1024
bash-3.1$ time python testsqlite.py
[...]
real0m30.421s
user0m0.015s
sys 0m0.015s
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Big difference in performance between Python and gcc

2011-06-01 Thread Roger Binns 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/01/2011 12:25 AM, Alessandro Marzocchi wrote:
>  The only thing that this program does
> is creating a database, making a table where a pair of integer maps
> 8192-bytes blobs and writing 100k rows in it. Any suggestions of what
> I could be doing wrong?

A major difference I see is that you are storing strings in the Python
version but blobs in the C version.  Additionally the contents are different
between the two being all '0' for the C while '01234567' for the Python.  To
make them identical use buffer() around the Python string which will then
cause it to be treated as blob at the SQLite level.

Another difference is that your timing does not include program startup for
Python but does for C.  Finally the databases have different file names.
I'll bet that virus scanners and backup software are interfering to some
degree during startup and operation.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3l7rAACgkQmOOfHg372QS29gCfQ6hWfdEojNbnAb1knuxIWtUO
NkEAnRzR0gQvz3W3caCUrEsBUuOyt6iD
=S7lS
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Big difference in performance between Python and gcc

2011-06-01 Thread Alessandro Marzocchi 
Hello,
I made some preliminary tests for an application storing big
chunks of data in a sqlite database. I did firsts tests with python
and they gave me quite impressive results. I then tried to make the
same test using C. I expected to get execution times to be the same of
those of python. However I was surprised as the performance got a lot
worse, with execution times being more than 3 times more. I tried
everything I could think of and also peeked at python module's source
but i couldn't find any way to get C program performance to match
python's one. Any suggestion of what could i be doing wrong? I include
both python and C source code's. The only thing that this program does
is creating a database, making a table where a pair of integer maps
8192-bytes blobs and writing 100k rows in it. Any suggestions of what
I could be doing wrong?

Note: These are the results i get for Windows/MinGW environment. I
have no Linux box at hand at the moment.
-- Python results
bash-3.1$ python --version
Python 2.7rc2
bash-3.1$ time python testsqlite.py
0
1
2
3
4
5
6
7
8
9
30.8555624521

real0m31.249s
user0m0.015s
sys 0m0.015s

-- C results
bash-3.1$ gcc --version
gcc.exe (GCC) 4.5.0
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
bash-3.1$ gcc -O2 test.c sqlite/sqlite3.c && time ./a.exe
0
1
2
3
4
5
6
7
8
9

real2m33.376s
user0m0.015s
sys 0m0.015s

-- Python script
conn = sqlite3.connect('test1.sqlite')
c=conn.cursor()
c.executescript('''CREATE TABLE IF NOT EXISTS values_log(acquisition
INTEGER,chunk INTEGER, acq_data BLOB);
 CREATE INDEX IF NOT EXISTS values_step ON
values_log(acquisition,chunk);
  ''' )

conn.commit()
def f():
  data="01234567"*1024
  with conn:
for i in range(0,10):
  conn.execute("INSERT INTO values_log VALUES (?,?,?)",(1,i,data))
  if not i%1: print i
conn.commit()
ret=timeit.timeit(f,'gc.enable()',number=1)
print ret

--- C source
#include "sqlite3.7.6.3/sqlite3.h"
sqlite3* db;
char* db_err;

int main(int argc,const char *argv)
{
  int ret;
  sqlite3_stmt *db_stm;
  sqlite3_open("testDB.sql", );
  if(SQLITE_OK!=(ret=sqlite3_exec(db, "create table if not exists
'helloworld' (acq integer, chunk integer, data blob);"
  "CREATE INDEX IF NOT EXISTS
acq_index ON helloworld(acq,chunk);"
  , NULL, 0, _err)))
  {
fprintf(stderr,"sqlite error in sqlite3_exec() [%d]",ret);
return -1;
  }

  if(SQLITE_OK!=(ret=sqlite3_exec(db, "PRAGMA synchronous=OFF;", NULL,
0, _err)))
  {
fprintf(stderr,"sqlite error in sqlite3_exec() [%d]",ret);
return -1;
  }

  if(SQLITE_OK!=(ret=sqlite3_exec(db, "begin transaction;", NULL, 0, _err)))
  {
fprintf(stderr,"sqlite error in sqlite3_exec() [%d]",ret);
return -1;
  }
  if(SQLITE_OK!=(ret=sqlite3_prepare_v2(db,
"INSERT INTO helloworld VALUES (?,?,?)",
-1,
_stm,
NULL
  )))
  {
fprintf(stderr,"sqlite error in prepare() [%d]",ret);
return -1;
  };

  int i;
  char data[1024*8+1];
  for(i=0;i<1024*8;i++)data[i]='0';
  data[1024*8]='\0';
  for(i=0;i<10;i++)
  {
if(!(i%1))printf("%d\n",i);

if(SQLITE_OK!=(ret=sqlite3_bind_int(db_stm, 1, 1)))
{
  fprintf(stderr,"sqlite error in bind()");
  return -1;
}
if(SQLITE_OK!=(ret=sqlite3_bind_int(db_stm, 2, i)))
{
  fprintf(stderr,"sqlite error in bind()");
  return -1;
}
//if(SQLITE_OK!=(ret=sqlite3_bind_blob(db_stm, 3, data,-1,
SQLITE_STATIC/*SQLITE_TRANSIENT*/)))
if(SQLITE_OK!=(ret=sqlite3_bind_blob(db_stm, 3, data,8192,
SQLITE_STATIC/*SQLITE_TRANSIENT*/)))
{
  fprintf(stderr,"sqlite error in bind_blob() [%d] ok=%d",ret,SQLITE_OK);
  return -1;
}
ret=sqlite3_step(db_stm);
if(ret!=SQLITE_DONE)
{
  fprintf(stderr,"sqlite error in sqlite3_step() [%d]",ret);
  return -1;
}
if(SQLITE_OK!=(ret=sqlite3_reset(db_stm)))
{
  fprintf(stderr,"sqlite error in sqlite3_reset() [%d]",ret);
  return -1;
}
sqlite3_clear_bindings(db_stm);
  }
  if(SQLITE_OK!=(ret=sqlite3_exec(db, "commit;", NULL, 0, _err)))
  {
fprintf(stderr,"sqlite error in sqlite3_exec() [%d]",ret);
return -1;
  }

  sqlite3_close(db);
}
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users