Boost logo

Boost :

From: Aviad Rozenhek (aviadr_at_[hidden])
Date: 2004-07-27 04:17:30

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_at_[hidden]>
Subject: Re: [boost] performance: pool cleanup takes too long
To: boost_at_[hidden]
Message-ID: <20040722234853.09879c08.laguna_at_[hidden]>
Content-Type: text/plain; charset=US-ASCII

On Wed, 21 Jul 2004 17:59:40 +0200
"AviadR" <aviadr_at_[hidden]> 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, 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at