Re: [boost] Status of property_tree library

From: David Abrahams (dave_at_[hidden])
Date: 2008-05-01 10:20:45

on Wed Mar 12 2008, "Marcin Kalicinski" <kalita-AT-poczta.onet.pl> wrote:

> I'll try to shed some light on what has happened to property_tree since
> review and why it's been dragging.
>
> Since review I had some feedback about the library. The issue raised most
> frequently was unsatisfactory performance. Ptree does too many memory
> allocations, and thus is fairly slow and unsuitable for many users. Plus
> some of the original parsers (XML parser specifically) were really slow and
> took ages to compile, especially on gcc. Because this is headers only
> library that is supposed to be lightweight, this was a serious problem.
>
> To solve it I spent some months implementing a very fast in-situ XML parser
> for the library (called rapidxml - see rapidxml project on sourceforge).
> This was finished in August last year and integrated with property tree. It
> works very well and is so fast that time to parse XML is now totally
> insignificant compared to the time it takes to build a ptree from the parsed
> data.
>
> The allocations problem remains. I have been unable to come up with a scheme
> that would reduce the number of allocations without compromising simplicty
> of the library. The key point is that I want to maintain validity of
> iterators in presence of insertions/erases. This rules out array based
> containers. The best I can think of is a custom list implementation. That
> has potential to reduce number of allocations by roughly 30%, which is not
> enough IMO.

Did you think about using something like
http://svn.boost.org/trac/boost/browser/trunk/boost/detail/quick_allocator.hpp
?

> On top of that I'm not sure whether the heavy type-parametrization of the
> library (i.e. lots of template parameters everywhere) is a good thing. It
> definitely makes it harder to document, use and understand. In all the the
> feedback I got there is no evidence of anyone actually using these template
> parameters. 

That's a good sign that they're not solving any real problems.  But
we've all made that mistake at one time or another; it can be hard to
remember that generic design proceeds from concrete (non-generic) use
cases.

<snip>

> If someone could help with the docs toolchain (Quickbook experts? Any
> alternatives?) I'm happy to do the rest. I should probably give up on trying
> to speed it up further and concentrate on getting it into releasable state.

Do you have the help you need, now?

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com