Re: [boost] [btree] Status report

Subject: Re: [boost] [btree] Status report
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-05-19 14:07:12

On Thu, May 19, 2011 at 3:24 AM, Rutger ter Borg <rutger_at_[hidden]> 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/RandomAccessHandleService.html

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