Re: [sqlite] Build static under Solaris
Anders Persson wrote: i try to compile it with gcc --static -I../sqlite -L../sqlite/.libs -o db-test db-test.c -lsqlite3 But i get errors like Undefined first referenced symbol in file fdatasync ../sqlite/.libs/libsqlite3.a(os_unix.o) ld: fatal: Symbol referencing errors. No output written to db-test collect2: ld returned 1 exit status man fdatasync on solaris will tell you that you need to add -lrt for fdatasync. so do something like gcc --static -I../sqlite -L../sqlite/.libs -o db-test db-test.c -lsqlite3 -lrt Cheers, Phuah Yee Keat
Re: [sqlite] Build static under Solaris
Anders Persson wrote: Phuah Yee Keat skrev: so do something like gcc --static -I../sqlite -L../sqlite/.libs -o db-test db-test.c -lsqlite3 -lrt Okej tested and i got ld: fatal: library -lrt: not found ld: fatal: File processing errors. No output written to db-test collect2: ld returned 1 exit status On my solaris 8 on sparc machine, I do not have a librt.a, so I think --static would not work. Try doing away with the --static flag. Why do you want to compile static anyway? For me, i just compile sqlite3 into my app statically (because its not native), other native libraries are dynamically linked. Cheers, Phuah Yee Keat
[sqlite] sqlite3 -version
Hi, Is there any specific reasons that sqlite3 -version is returning 1 instead of 0? I am using sqlite3 -version to store the sqlite3 version in one of my build scripts, inside MAKEFILE, and I have to do -sqlite3 -version to get make to ignore the error. As I understand, most of the tools return 0 for a -version or --version query. Cheers, Phuah Yee Keat
Re: [sqlite] Performance Difference on Linux Kernel 2.4 and Kernel 2.6
[EMAIL PROTECTED] wrote: Your script requires 1002 separate ACID transactions. Each such transaction should require at least 2 complete revolutions of your disk drive platter - meaning that the minimum time to complete your script should be 16 seconds. The 2.4 kernel finished faster than this, which tells me that the 2.4 kernel probably does not implement the fsync() system call correctly. I have heard reports of this but could not verify it. What this means is that if you loose power unexpectedly, the 2.4 kernel might corrupt your database. Probably since the ReiserFS does a good job of journalling itself, you won't corrupt the database, but your transactions will certainly not be Durable. The 2.6 kernel is much slower because reiserFS is inefficient in its implementation of fsync(). Thanks for the thorough explanation. I understand it better now. You script does not measure how fast SQLite processes inserts. It measure how fast it does transacxtions. If you put a BEGIN and a COMMIT at the beginning and end of your script, I think you will find that the whole thing will run in a fraction of a second under either kernel. Yeah, I have tried that, but my benchmarking is on individual transactions instead of everything in one transaction. Thanks for the great help! -- D. Richard Hipp [EMAIL PROTECTED] Cheers, Phuah Yee Keat
[sqlite] Strange Behaviour on Solaris 8 on Sparc
Hi, I am currently running some tests to decide whether to use sqlite, and bump into some strange behavior. I compiled sqlite 3.3.4 from source and installed it on a solaris 8 on sparc without any updates. I run the same scripts (which insert 1000 entries without BEGIN/END block), on the same machine, but in different directories, getting totally different results: ### # In the db1 directory: ### [EMAIL PROTECTED]:~/db1$ time cat /export/home/ykphuah/test.sql | sqlite3 test.db real3m53.708s user0m0.710s sys 0m2.140s [EMAIL PROTECTED]:~/db1$ time cat /export/home/ykphuah/test.sql | sqlite3 test.db real3m48.267s user0m0.590s sys 0m2.120s [EMAIL PROTECTED]:~/db1$ time cat /export/home/ykphuah/test.sql | sqlite3 test.db real3m48.435s user0m0.630s sys 0m2.100s [EMAIL PROTECTED]:~/db1$ ### # In the db2 directory: ### [EMAIL PROTECTED]:~/db2$ time cat /export/home/ykphuah/test.sql | sqlite3 test.db real0m12.523s user0m0.650s sys 0m1.960s [EMAIL PROTECTED]:~/db2$ time cat /export/home/ykphuah/test.sql | sqlite3 test.db real0m6.296s user0m0.490s sys 0m1.720s [EMAIL PROTECTED]:~/db2$ time cat /export/home/ykphuah/test.sql | sqlite3 test.db real0m6.264s user0m0.470s sys 0m1.750s [EMAIL PROTECTED]:~/db2$ I am really puzzled as to why there's so much difference in the time to execute the same script on the same box just in different directories, thinking that it might be placement of the directories in the physical disc itself causing the fsync calls to differ so much? Is there any way where I can provide more information to help you guys help me? Thanks in advance. Cheers, Phuah Yee Keat
[sqlite] Performance Difference on Linux Kernel 2.4 and Kernel 2.6
Hi,
I would like to take a shot at asking this question here instead of
Linux kernel mailing list just in case anyone here have encountered this
issue before.
I am running sqlite 3.3.4.
On a desktop slackware 10.2 machine, I have installed two stock kernels
2.4.31 and 2.6.13. The box is using reiserfs.
I have attached a script that I use to generate a sql script to test.
The 2.4 kernel took 5 seconds to finish the sql script but the 2.6
kernel took 50 seconds. Here are the GNU time output:
Kernel 2.4===
0.31user 1.54system 0:06.27elapsed 29%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (686major+184minor)pagefaults 0swaps
Kernel 2.6===
0.48user 1.40system 0:52.24elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1040minor)pagefaults 0swaps
Any help will be greatly appreciated. I could provide more information
on the system as required.
Thanks in advance,
Phuah Yee Keat
#!/usr/bin/perl
printf DROP TABLE IF EXISTS t1;\n;
printf CREATE TABLE t1(a INTEGER, b INTEGER);\n;
for ($i=0;$i1000;$i++) {
$r = int(rand())*10;
printf(INSERT INTO t1 VALUES(%d,%d);\n, $i, $r);
}
