Still missing the newline :)

propably:
m_Offset = std::max(size, align)
m_Start = aligned_alloc(align, m_PoolSize)

Vulcan doesn't seem to like std::aligned_alloc, is it not on C++17?

And std::max(size, align) is wrong, sorry for the advice.

Might work with boost::align::aligned_alloc but only if you really need it.

I found this expression:

size % align == 0 ? size : size + (align - size % align);

on stackoverflow

Might be overkill for our use case but supposedly covers all potential alignment situations.

Regarding aligned_alloc I think that is only used either for interfacing with esoteric apis or as a potential performance optimization.

My testing shows no performance improvement but rather a slight but consistent slowdown when using std::aligned_alloc or an equivalent cross platform function that I wrote. So it seems like malloc is the best choice.

Here is the aligned alloc function I wrote, in case we do need it for some reason:

std::pair<void*, void*> AlignedStorage(size_t align, size_t size)
{
        void* storage;
        align = std::max(align, (size_t)32);
        void* start = storage = malloc(size + align);
        // the while loop could be replaced with bit shift
        while (reinterpret_cast<size_t>(start) % align != 0) start = static_cast<unsigned char*>(start) + 1;
        return std::make_pair(storage, start);
}

I could do
m_Start = static_cast<void*>(new unsigned char[m_PoolSize]);
But that seems less readable to me

Could be a unique_ptr of that size using make unique? ,(Just wondering)

Yeah probably could be, I don't think there is any need but I guess there isn't really any cost either.

Like checking if size is one? If it is then begin + 1 == end so for_each will do nothing anyway.

Offset is added on line 60 regardless of if realloc is called.

My understanding of const keyword on methods is that it informs the compiler that none of the object's members will be altered within this call. Deallocate alters m_OpenList.

^

1. I don't know how.

2. IMO it's more complicated without clear benefit.

My thinking here was that in order to reduce lag the primary target shouldn't be speed in general but rather speed in the worst case turns. Real-time specialized code. I think those worse case turns are at the start of a battle, when large numbers of projectiles spawn. Any performance boost down in the 'valleys' is just bonus to the primary goal of reducing the height of the 'peaks' of the turn length graph. During these peaks there will be no empty slots. The number of operations per step is 2 for iterating the pool directly or with a linked list. What led me to believe that not using the list would be better is the reduced bookkeeping on allocation and deallocation.

Some probably half baked further reasoning based on my limited understanding of hardware:

1. Omitting headers means more components can fit into a hardware cache line. The most common components have one or two integers as data only, so even a single pointer makes a difference. This could be addressed by writing a jump pointer into the unused component memory, at the cost of adding a minimum component size and some probably confusing union code.
2. To iterate a single step on a linked list you have one dereference of variable distance and one of constant distance. To do the same when iterating the pool directly you have a dereference of constant distance and checking if an integer is 0. Maybe a processor can check if an integer is 0 faster then it can do a variable dereference? According to Big O analysis it shouldn't matter but it seems worth testing.

So with this thinking in mind I decided the best plan would be to write both versions and test them against each other. So far I have only written this one.

It could end up that even if no list is better in isolation list is better combined with code which takes advantage of the down time better. One option here is calculating a dynamic time budget for SpiderMonkey GC slice, rather then the current strategy of always giving 30ms per turn. Incidentally I think further optimization could be found in the GC code by removing the shrink every 500 turns.

Similarly, down time could be used to compact the pools. I know some components related to pathing cannot be moved, will have to find out if any other component types can't move.

I think we're ok with this version for now. Was mainly thinking back to some similar allocators I've written in the past. But this current version already gives a nice performance boost, so it's likely not worth the trouble in this case. On component movement, I'd expect it'll be pretty tricky to try moving objects around here.

We are storing when the end of the current pool is. If it's the one we are currently extending with new allocations when m_OpenList is empty then we need m_Back. Otherwise this is an older pool that has already hit max size so the end is the start plus the max pool size.

yes, see response on line 86.