Subject: Re: [boost] [pool2] Requests for comment
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2012-10-16 08:00:15
On Tue, Oct 16, 2012 at 9:24 AM, DUPUIS Etienne <e.dupuis_at_[hidden]> wrote:
> The pool2 I am designing will address all issues; I am not finished as I
> am currently trying to know what users need.
Hi, I just wanted to comment on this quickly.
I'm making video games (and digital narration stuffs too).
I don't make games always like in traditional industry, where both object
pools and small allocation pools are used heavily (and arena too).
I mostly use only object pools in my own project, for some game-specific
state objects.
Last week I finished implementing a template factory class (not really
generic though) that have the following features:
1. it have a "pool" of objects, meaning it have to be stable (objects must
not move in memory).
2. it provide a way to go through all the elements very fast
3. it provide an "index" by "id" of objects
Basically this means I wanted a std::vector of elements, which should be
reserved and would not go higher than a specific size,
plus a map<id, element*> for the index (that is not interesting here).
The problem was that I didn't want to limit the number of elements, to
allow the same code to be usable by the in-game editor,
meaning I cannot really fix a maximum of elements before having edited some
"map" of the game. (maybe I'll fix later, but I don't want to for some
reasons).
Having done the same system before with boost::pool (from 1.44 version I
think) and I was not happy with the performances, I didn't bother trying
using it.
So I implemented it first with std::vector and std::map, then I decided to
try boost::stable_vector instead.
It have some speed disavantages, but I made some tests and it appear that
if you first resize (not reserve) the stable_vector,
then it is very fast to go through the element, almost as fast as with a
std::vector. (in my tests at least)
Then I thought that, as I want objects to be created and destroy in an
unpredictable order, a solution would be to make them optional
Currently, my solution is implemented by using a boost::stable_vector<
boost::optional<T>> which seems efficient (to my surprise).
In particular it allows me to go through all elements in a fast way, not
like the current pool.
It also allows me to fully construct and destroy objects like in a pool
instead of "reusing" them, like often done in other game companies,
which don't involve constructor and destructor and is source of maintenance
bugs.
I don't know yet the drawbacks of using this combination compared to using
a better pool implementation, so
I just wanted to give this feedback see if there are some things you're
working on for pool2 that would make things better.
Hope it helps.
Joel Lamotte