It sounds like you're getting ahead of yourself a bit. Vector allocation is already on the heap, but I don't think this is a heap/stack issue. It sounds like you want to do something unusual with lifetime management. If the 'node' is a POD then just use vector without pointers. The indirection you're introducing here is going to make iterating the vector very costly for no reason. It sounds like these objects have destructors though? I kind of want to know what's going on here, but even in that case you'd probably be better off doing manual mark and sweep if you need delayed destruction (why?).

The use case will be like:

Node* node1 = Node::Create();
// --> #Create is a static function where new Node is allocated to a memory pool, returning the pointer to the object.
//     Everything about it will be handled by the pool.

Node* node2 = Node::Create();

node1.addChild(node2);

// ... addChild is:

void addChild(Node* node)
{
    _children.push_back(node); // --> where _children should only point to those objects allocated (vector<Node*>).
}

In that case, if I make vector not a pointer to the Nodes, aren't I will be copying the values instead, which costs more? like _children.push_back(*node)?

And yes it has destructors. This node real case is an Entity in Entity-Component system. So yeah, entities are very active as part of the scene. As for why, I want them to get in (allocated) and out (deleted) off the game gracefully at the right timing, like when player pauses the game, changing scene, finishing a turn or combo input in turn based game, and of course when there's too much being already allocated and needs to be reused, etc. Small things that shouldn't let the screen stutters cause of it.

Shouldn't an ECS entity just be a unique numeric identifier?

I'm not sure what's going on with 'node' being an entity and having children.

I'm also not sure what you're getting out of using a memory pool here. Is Node polymorphic?

My concern is that you may be spending more on cache misses while working through the vector of pointers than you're saving on not copying whatever Node is. More directly, I'm wondering if you can't just work with the stored objects instead of spitting out pointers and working from a distance.

I'm not sure how you want it to be a unique numeric identifier (only), but it's basically a scene graph. I want this entity to respect its parent (not parent class) on changes, such as the entity's parent's position component and whatever, therefore I need them to have children.

No in this case, "Node" is not polymorphic. The pool is specific for this guy, it's a very simple pool.

I'm not sure about the cache misses. I mean, if I make a copy, wouldn't it be a double? wouldn't that cost more? or does the vector<Node> also points to the object directly? or you mean you worry that it'll be a trouble when I use the vector<Node*>, like when I iterate them or whatevs because it is working indirectly (always got to point to the object first on usage)?

Ah.

If there's already that much going on then the pointers are probably less significant than they would be otherwise. What I was driving at was to not use a pool and just use the contiguous storage of a vector of nodes, but if your iteration has to be scattered and in a weird order then the indirection may be necessary. On the other hand, if you can safely iterate through the nodes in any arbitrary order then the cache-efficient way to go about it would be to just go straight through them in memory from start to finish.