On 10/16/2013 02:59 PM, Dick Hollenbeck wrote:
On Oct 16, 2013 7:53 AM, "Dick Hollenbeck" <[email protected] <mailto:[email protected]>> wrote: > > Looks promising, and super job on the presentation. > > Once you have it working, give some thought to using a special purpose allocator for the elements of your container. A memory pool scheme, anchored on the container, might pay dividends if it removes the size test for element allocations. If you want the pool anchored on the container, then overloading operator new is not best, but rather have a container function do the allocations of its elements (from a pool it owns.) Invariably this means having an "in place" new operator for the element, not a normal new operator overload. Such anchoring of pool in container is a separate decision from deciding to use a fixed block allocator at all. The fixed block allocator will be worth it regardless of where the pool lives. If you have to move elements from one container to another, then anchoring the pool on the container is not appropriate. But you could then have a class that held all your containers and a pool common to those containers. I bring this up because when instantiating hundreds of thousands of elements, memory heap calls can be the bottleneck.
Thanks for the suggestion - I like the idea. I have briefly read the boost::pool project page and initially it seems to be an easy solution to the problem. Especially that nodes are very likely going to be POD structures with fixed size. I guess it is already included in C++11 as the emplace() function that is available for many std containers.
Regards, Orson _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
