On Thu, May 19, 2011 at 3:24 AM, Rutger ter Borg <rutger@terborg.net> wrote:
On 05/18/2011 08:54 PM, Beman Dawes wrote:
Feedback welcome!
Thanks,
--Beman
Hello Beman,
looks interesting. I'm not able to find the bootstrap.sh file mentioned in the README, it seems to be missing in the repository.
It comes from the Boost repo when the install instructions are applied.
I have four remarks on the current state
1) I think having the in-memory representation to be identical to the on-disk representation is a very serious limitation.
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. The limitations can be overcome by using the B-tree within the implementation of some higher level abstraction.
Wrapping around it by overloading the output stream operators doesn't seem efficient.
That's also my assumption.
I'm not advocating Boost.Serialization; rather something like Asio's buffer-handling mechanism (which, in turn, can handle Boost.Serialization).
I'm not familiar with that mechanism. Chis is here at BoostCon so I'll ask him.
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?
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?
4) have you looked at http://goo.gl/r8Z2m
Yes, quickly. It appears the proposed Boost B-tree's caching scheme and pack optimization provide similar benefits. and/or http://goo.gl/lvc9A ? I find that one more interesting and will study it more carefully. But the proposed containers have highly tunable performance, and were designed with many of the same concerns of that paper in mind WRT disk access versus cache lines. Thanks, --Beman