Re: [Boost-users] How to improve property_tree performance

Subject: Re: [Boost-users] How to improve property_tree performance
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-10-13 14:54:33

On Wed, Oct 13, 2010 at 2:47 AM, Bo Jensen <jensen.bo_at_[hidden]> wrote:
> On Wed, Oct 13, 2010 at 8:33 AM, Sebastian Redl
> <sebastian.redl_at_[hidden]> wrote:
>> On 13.10.2010 10:15, Bo Jensen wrote:
>>>
>>> I tried that, it was only slightly faster. I also tried to do a bunch
>>> of independent trees and then merge them later, but still same speed.
>>> Is it correct, that you can not choose the underlying storage method
>>> or preallocate some space ? In my case I know exactly the sizes of
>>> each tree and number of items.
>>>
>>
>> No, because of the way PTree is structured at the high level (nesting trees
>> where each branch can be treated as an independent tree), providing generic
>> allocator support is impractical. Internally, a tree node consists of its
>> local value and a node-based container of children, so preallocation through
>> an interface would only be able to provide storage for that particular node,
>> and would also require a special allocator.
>> However, if you want to try the performance effect of using a stateless
>> Boost Pool allocator, I believe all you have to do is add it to the
>> base_container typedef in
>> boost/property_tree/detail/ptree_implementation.hpp, near the top. See that
>> big multi_index_container? That's the storage for child nodes. If you give
>> it an alternative (stateless!) allocator, it will be used.
>>
>> Sebastian
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>>
>
> Thanks for the input, I will try it out. Otherwise I might use the
> serialization with xml, since my usage is so simple.

You could just try using Spirit/Karma for that, there is about nothing
faster then those for input/output streaming.  You will have to define
your own format (xml is *easy* to emulate it in, see its examples,
already done), but it would certainly be faster then any other method
if you have a real need for speed.