Re: [sqlite] Memory-mapped I/O [was: SQLite 3.7.17 preview - 2x faster?]

2014-02-10 Thread Nico Williams
On Sat, Feb 8, 2014 at 7:26 AM, Richard Hipp wrote: > OpenBSD lacks a coherent filesystem cache. That is to say, changes to a > file made using write() are not necessarily reflected in mmap-ed memory > right away. And change to a mmap-ed segment are not necessarily reflected >

Re: [sqlite] Memory-mapped I/O [was: SQLite 3.7.17 preview - 2x faster?]

2014-02-10 Thread Nico Williams
On Sun, Feb 9, 2014 at 5:03 PM, Richard Hipp wrote: > On Sun, Feb 9, 2014 at 5:49 PM, James K. Lowden > wrote: > I suspect that adding msync() calls would wipe out any speed advantage for > using memory-mapped I/O. And since speed is the only advantage

Re: [sqlite] Memory-mapped I/O [was: SQLite 3.7.17 preview - 2x faster?]

2014-02-09 Thread Richard Hipp
On Sun, Feb 9, 2014 at 7:19 PM, Drake Wilson wrote: > Quoth "James K. Lowden" , on 2014-02-09 > 17:49:15 -0500: > > That's true, although it's not quite fair to say the filesystem cache > > isn't "coherent". It's just not the Linux implementation.

Re: [sqlite] Memory-mapped I/O [was: SQLite 3.7.17 preview - 2x faster?]

2014-02-09 Thread Drake Wilson
Quoth "James K. Lowden" , on 2014-02-09 17:49:15 -0500: > That's true, although it's not quite fair to say the filesystem cache > isn't "coherent". It's just not the Linux implementation. FYI, the term "coherent" I interpret as being used in the specific technical

Re: [sqlite] Memory-mapped I/O [was: SQLite 3.7.17 preview - 2x faster?]

2014-02-09 Thread Richard Hipp
On Sun, Feb 9, 2014 at 5:49 PM, James K. Lowden wrote: > > I know portability is important to the SQLite project. Is this > particular issue a matter of manpower, know-how, or policy? > > The mmap functionality in SQLite is completely portable to OpenBSD now, since as

Re: [sqlite] Memory-mapped I/O [was: SQLite 3.7.17 preview - 2x faster?]

2014-02-09 Thread James K. Lowden
On Sat, 8 Feb 2014 08:26:43 -0500 Richard Hipp wrote: > > > The memory-mapped I/O is only enabled for windows, linux, mac > > > OS-X, and solaris. We have found that it does not work on > > > OpenBSD, for reasons we have not yet been able to uncove; but as > > > a precaution,

Re: [sqlite] Memory-mapped I/O [was: SQLite 3.7.17 preview - 2x faster?]

2014-02-08 Thread Richard Hipp
On Fri, Feb 7, 2014 at 1:01 PM, varro wrote: > Regarding the following old post: > > Richard Hipp wrote: > > By making use of memory-mapped I/O, the current trunk of SQLite (which > will > > eventually become version 3.7.17 after much more refinement and testing) > > can

[sqlite] Memory-mapped I/O [was: SQLite 3.7.17 preview - 2x faster?]

2014-02-08 Thread varro
Regarding the following old post: Richard Hipp wrote: > By making use of memory-mapped I/O, the current trunk of SQLite (which will > eventually become version 3.7.17 after much more refinement and testing) > can be as much as twice as fast, on some platforms and under some > workloads. We would