On Fri, May 20, 2011 at 4:46 AM, Rutger ter Borg <rutger@terborg.net> wrote:
On 2011-05-19 20:07, Beman Dawes wrote:
Yes, agreed. But the assumption is that it is very, very, fast compared to an implementation that must translate between different external and internal representations.
I always assumed that file-access is orders of magnitude slower than DMA. Especially when the file isn't local. Another case might be convincing here: Keys that don't require translation, Mapped that requires it.
2) using a "path" argument to having a file open presumes a real underlying file. Although this is fine, maybe I would like to use an fstream?
What would a real-world use case be?
See below.
3) It would be nice if it would work with an asynchronous file-like services, like, e.g., Asio's RandomAccessHandleService, see
http://www.boost.org/doc/libs/1_46_0/doc/html/boost_asio/reference/RandomAcc...
I'd need stronger motivation that "it would be nice"! What would the benefit be?
There's an increased availability of network-based storage mechanisms, like, e.g., Amazon's S3. The combination of (such a) storage backend with a B-tree container delivers a NoSQL-stack, which I think is a considerable benefit.
Yes, of course. And such a stack might want to provide async operational functions. But they would be provided by a level above the basic B-tree package. Chris Kohlhoff and I discussed this yesterday. Neither of us can see any way for Boost B-tree to benefit from async approaches. A UB-tree (i.e. a B-tree that does multi-dimentional searches) might well benefit. But that isn't what is on the table at the moment.
To name a concrete example, using a distributed object store like Ceph's underlying RADOS, see http://ceph.newdream.net/wiki/Librados , as a storage-backend. Operations at this level don't require "expensive" file-system semantics.
I'll take a look. --Beman