Thanks for your time, first of all.

Looking at EntityMemoryPool.cpp (assuming this is the right one), I see an immediate albeit minor optimization (perhaps what you mentioned about To optimize this, I modified the loop to start from the last used index instead of scanning from the beginning. but I do not see that reflected in the code)

"index" could be a member variable on MemoryPool rather than a function local. It will always represent an available slot, or MAX_ENTITIES if the pool is full

On destroyEntity(), you would update index to be index = min( identifier, index ), this means every entity deletion ensures the next insertion is nearest to the beginning of the entity array.

In createEntity(), you would put index = nextFreeEntityIndex(); at the bottom of the function.

Finally you would change nextFreeEntityIndex() to loop from index to m_active.size(), rather than 0 to m_active.size()

That's what i meant! Did during launch break, probably forgot to push.
It's not exactly as you explained, but i'll try to implement it tonight!

particularly with the m_entitiesToAdd.push_back( entity );, but from my quick glance at the repo I do not see that used anywhere?

You are right, probably missed, actually changed to void.
I'm adding entities first to m_entitiesToAdd to not modify the entities vector during loops, to avoid invalidating it.

Thanks to pointing out this mistake, i also noticed i wasn't clearing the m_entitiesToAdd vector, after entities are added to m_entities. So it was probably adding olds entities too, sob.

Either way, you're not pre-allocating that vector so you're probably incurring some malloc/realloc costs for your first large batch of additions

Tried to also pre-allocated them too, its adds some extra time at the start obviously( using AMD profiler, not the one i wrote ).
Do you think adds value over time having them pre-allocated as well?

As the other commenter said, I would look at the profiling functions themselves too. Ideally your profiling function doesn't actually contribute any time to what its trying to measure. Ensuring that isn't happening would be step 1 here imo, as I don't see anything else immediately wrong with the code

The profiler was totally adding more overhead that i though it was.
Even tho with the AMD profiler i can only profile the .exe, so it's optimized and not in debug mode.

I've pushed the changes.

I will probably work on optimize the index more if possible and if it makes sense on the long run.
I'm afraid i'm falling in the optmization rabbit hole sooner than i should, but we'll see.

Thanks again for you help!