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
> 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
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 http://boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk