Re: [boost] [Countertree + Suballocator] New Version

Subject: Re: [boost] [Countertree + Suballocator] New Version
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2012-04-16 09:41:25

Francisco José Tapia wrote:
>
>  In the previous message Mr.Mathias said I have a little time
> for to attend this project (as I am doing now). I don't have
> time for to read all the interesting things which I see every
> day, but to attend the boost community is easy and a pleasure
> for me

I was going to reply to Mathias (Mr. Gaunard), that his conclusion was unjustified.  His perspective appeared to be that those putting work and family ahead of Boost work are unworthy to submit to Boost.  That perspective is wrong, and I presume he didn't mean to say that.

>  It is a stange  situation. I am the author, and say "the
> suballocator is a pool allocator, and when have a chuck of
> memory free, return it to the allocator". Mr Mathias respond
> that according the theory, a pool allocator don't do that and
> if do, it have a great cost in performance. The suballocator is
> the empirical demostration that this theory is not correct.

I was starting to get a little lost in Mathias's arguments, too.  Your allocator adapter, according to your tests, demonstrates high performance and the ability to return memory to the OS, which would seem to be the ideal.  I haven't studied your tests, so there may be testing deficiencies that have led to biased conclusions.  Your allocator adapter must be tested in numerous contexts to justify its addition into Boost, at least if it's to be used as anything other than a tool for use with your countertree.  However, it sounds promising enough to pursue.

It may also be possible to follow Mathias' advice regarding a per-container fast_pool_allocator to retain the performance benefits you've described using your allocator adapter.  However, it isn't clear that the same benefits would accrue because the container would have to force the pool allocator to return memory to the OS even before destruction to account for use cases in which the number of elements grows large and then drops again while the container continues to exist thereafter.  (Actually, looking again, I see that Mathias suggested multiple pools per container so that there was a greater chance of being able to free a given pool, thereby returning memory to the OS.  Either way, that puts the onus on the container and isn't as reusable.)

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.