I am using the object_pool interface, Calling on the object_pool::free () function. On more scrutiny it came down to this: I am not freeing the objects in reverse order of their creation. When I explicitly change the design to make it so, The pool works fine. It also works fine when I wait for the ~object_pool () To clean it up. So these problems remain: 1. when deallocating objects only once in the running of the program (on ~object_pool) and avoiding the cleanup problem stating earlier the pool classes still actually cause a minor downgrade of peformance rather than boosting it. This is the case both in ms-windows port (using Doug Lee's malloc to circumvent microsoft terrible malloc) And on linux port. 2. when not deallocating objects in the reverse order The penalty is overwhelming. For isntance when I turn off all pooling In my application the cleanup make take 3 seconds. Turning on pooling causes cleanup to take an excess of 10 mins ( I give up after that) Possible causes: 1. its not thrashing, because I tested it on a large memory machine. 2. perhaps it's the simple_segragated_storage::find_prev function Because its run time is linear with the size of the chunk. ------------------------------ Message: 5 Date: Thu, 22 Jul 2004 23:48:53 -0700 From: Mark Deric <laguna@laguna1.com> Subject: Re: [boost] performance: pool cleanup takes too long To: boost@lists.boost.org Message-ID: <20040722234853.09879c08.laguna@laguna1.com> Content-Type: text/plain; charset=US-ASCII On Wed, 21 Jul 2004 17:59:40 +0200 "AviadR" <aviadr@pob.huji.ac.il> wrote:
the cleanup part (which consists only of calling the pool release methods on allocated objects) on the other hand, takes many minutes (I usually give up after 5 minutes)
Are you freeing each on the allocated chunks using pool.free(), or pool.release()? They would need simple_segregated_storage.nextof() Or are you calling ~pool()? The call to ~pool() doesn't use nextof() and should be pretty quick.