Monday, March 22, 2004, 1:46:00 PM, Mark wrote: >> I have run experiments to see how much faster SQLite might >> work if it didn't invalidate its cache so quickly. The >> answer is about 15%. So it is probably worth looking into >> someday. Note that such a change will be backwards but >> not forwards compatible. Suppose this change happened >> for version 2.9.0. Then a 2.9.0 library would be able >> to read and write a 2.8.13 database file, but a 2.8.13 >> library would not be able to read and write a 2.9.0 >> database file. Such a change it not to be made lightly >> and without careful consideration.
> I don't follow. Why would this cause compatibility issues? Note that presently (<= 2.8.13), the only mechanism used to coordinate transactions is the file lock. > Presumably some benefit could be obtained just by > not throwing away the cache at the SQLITE_READLOCK to > SQLITE_UNLOCK transition, but waiting until the next > SQLITE_UNLOCK to SQLITE_READLOCK transition. > If at that time there have been no write transactions > since the cache was created, it can continue to use > it, otherwise it would then throw it away. It has no way of knowing (save diffing the db) that "there have been no write transactions." [...] > While I'm making suggestions despite near-total ignorance > of sqlite :), have you measured what improvement would > be obtained by using readonly mmap() for readers, rather > read()? It would save some malloc churning as well as > a memory copy. Performance could be additionally tweaked > with madvise(SEQUENTIAL) when suitable. These functions are not in ANSI C. e --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
