2011/11/2 Nico Williams <n...@cryptonector.com> > > But that's NOT what SQLite3 is doing. SQLite3 is doing random I/O. > And the OS sees the random I/O pattern and concludes it's better to > not read the whole file in. So for those 10K inserts you pay -worst > case- 10K I/Os. At ~12ms per random I/O (likely the seek times for > your disks) you're talking 120s, so you're actually far from the worst > case -- even at 7ms seek time you're talking about twice the time > you've seen in the worst case. > > Linux will not read the whole file in, but Windows eventually does. The inserts go progressively faster when they are reaching halfway, and Windows reads very large pages from disk, even if you request only 10 bytes. So in reality a very large percentage of these 10K I/O's will come from a buffer (either Windows one or your harddrive's buffer), and will not result in any physical reads from disk. Ofcourse you're right that these random reads will be slower than a sequential file-copy, because they are random, and not large, continous blocks.
>Actually, it might be nice if SQLite3 had a function or open >flag by which to request that the whole thing be read into memory, >because the OS certainly won't know to do it. I completely agree, because all the current methods (copy the file to 'null', etc.) didn't work well. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
