Re: [sqlite] Linking libsqlite statically
On 15-Aug-05, at 7:12 PM, D. Kettler wrote: g++ -o kumacgen kumacgen.cpp /usr/lib/libsqlite3.a add -lpthread to your link line. ck
Re: [sqlite] Linking libsqlite statically
On 15-Aug-05, at 5:39 PM, D. Kettler wrote: Project? DLL? Visual Studio? I said I was using Linux and g++ just link with full path to libsqlite3.a example: gcc -o foo foo.o /usr/local/lib/libsqlite3.a man gcc ck
Re: [sqlite] sluggish operation on os x?
On 21-Feb-05, at 11:11 AM, [EMAIL PROTECTED] wrote: OK -- so, you are willing to accept the risk of non-recoverable database corruption in the event of power outage or other kinds of catastrophic system failure (including the plug being pulled on a FireWire drive without it being properly unmounted)? I.e. that risk is perceived to be acceptably small that the performance hit is not justifiable? The performance hit is much larger than the risk, so in some cases, no FireWire drives and there is an UPS, the risk is acceptable for the performance gain. To ask the question an other way since FreeBSD, Linux, Solaris, etc do not support F_FULLFSYNC is it safe to run any kind of database on them ;) ck
Re: [sqlite] sluggish operation on os x?
On 21-Feb-05, at 10:39 AM, [EMAIL PROTECTED] wrote: It is a trade off between guaranteed data integrity and performance. If there happen to be a bunch of other apps writing to the disk when you do a SQLite transaction, then all of that data has to be flushed to the disk. As Domnic said, fsync() does not guarantee that the bytes hit the platter on any system. Pull the plug after a COMMIT and you are very likely going to see only part of the pages written. You can also use the 'synchronous' pragma to control the number of F_FULLSYNCs executed during any single transaction. By default, it will be three-- probably too excessive. I sill want the "normal" fsync() called and using this pragma means fsync() is not called. The best way to guarantee maximal performance is to bunch up your INSERT and UPDATE statements into transactions as much as possible. This is often true regardless of the presence of F_FULLSYNC. My application does this and the performance was still very poor on OS X with F_FULLSYNC on. Since OS X is the only OS which has F_FULLFSYNC it would be nice to make the use of it a configure option. ck
Re: [sqlite] sluggish operation on os x?
I noticed this as well, so I profiled my call and found sync was taking forever. I removed the following fcntl call, rc = fcntl(fd, F_FULLFSYNC, 0);. Performance was back to normal. ck
Re: [sqlite] Reducing the SQLITE_MAX_PAGE_SIZE for embedded systems usage
See check in 1937 which changes: "Modify btree.c so that is allocates big data structures using malloc() instead of allocating from the stack. Stack allocations cause problems for embedded systems and pthreads implementations that only allocate a limited amount of stack space." You will need to build from cvs. A side question, can't Windows or Windows/CE change the stack size for a thread? You can with pthreads on all Unix platforms, which allows you to handle the above case. I set all my threads stack size to 1MB to avoid running out of stack in a thread, which for the embedded people might not be an option. ck
Re: [sqlite] SQLite & stack size
On 3-Sep-04, at 9:31 AM, Christian Smith wrote: How often does the balancer run? Could the space for the balance routine be allocated with the sqlite structure? It is opaque anyway, and is allocated only once, so there should be no penalty in performance over the current stack implementation, and only a single thread should ever be using a sqlite structure at a time. Or you could set the thread stack size to something reasonable when you create it, which accomplishes the same thing. ck
