Note that according to the Microsoft documentation opportunistic locking is
only used when overlapped I/O is enabled. Of course, this is from Microsoft
documentation, so it has to be taken with a really huge boulder of salt.
Anyway, long and short is that you may be able to get windows to help less by
adding some flags to the file open.
Perhaps try the following patch and see if it helps:
--- sqlite3.c Sun Aug 19 12:32:41 2012
+++ ..\sqlite3.c Sun Aug 19 11:54:19 2012
@@ -33446,8 +33448,14 @@
}
/* Reports from the internet are that performance is always
** better if FILE_FLAG_RANDOM_ACCESS is used. Ticket #2699. */
-#if SQLITE_OS_WINCE
+#if SQLITE_OS_WINCE || SQLITE_WIN32_FILE_RANDOM
dwFlagsAndAttributes |= FILE_FLAG_RANDOM_ACCESS;
+#elif SQLITE_WIN32_FILE_SEQUENTIAL
+ dwFlagsAndAttributes |= FILE_FLAG_SEQUENTIAL_SCAN;
+#endif
+
+#ifdef SQLITE_WIN32_FILE_WRITETHROUGH
+ dwFlagsAndAttributes |= FILE_FLAG_WRITE_THROUGH;
#endif
if( isNT() ){
Then set SQLITE_WIN32_FILE_RANDOM and SQLITE_WIN32_FILE_WRITETHROUGH when
compiling the amalgamation (note the line numbers in the patch are not correct,
they are for an earlier version of the amalgamation). The former will stop
windows from helping so much, and the latter will ensure that writes to sqlite
opened files do not get cached. This may or may not defeat the ill-conceived
behaviour of Windows. Then again, it might not. Windows is pretty hopeless
when it comes to I/O and it always has been thus.
---
() ascii ribbon campaign against html e-mail
/\ www.asciiribbon.org
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
