Boost logo

Boost :

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

on Wed Mar 12 2008, "Marcin Kalicinski" <> 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

> 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


> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at