ResourceAwarePool Optimizations

[kab163]

Updating the PendingList to a PendingMap, including:

• storing an iterator for each pending chunk
• using an unordered multimap for the pending map with key std::optional<Resource> and Chunk* values
• In release function, pending chunks (if finished) are freed directly instead of being copied to the free map first

Waiting on Camp PR to get merged first, then this will include a Camp update

[MrBurmark]

If you're storing multiple chunks per resource why not do something like std::unordered_map<camp::Resource, std::vector<Chunk*>> to avoid storing multiple copies of the same key?

[MrBurmark]

Also why is the camp::Resource optional?

[kab163]

Also why is the camp::Resource optional?

Because the default constructor is deleted and I kept getting compiler errors when doing something like PendingMap my_map{}

[MrBurmark]

I thought that was only a problem if the value type was not default constructible.

[kab163]

If you're storing multiple chunks per resource why not do something like std::unordered_map<camp::Resource, std::vector<Chunk*>> to avoid storing multiple copies of the same key?

Sometimes we need to search for a chunk given a resource, sometimes we need to search for a chunk given a ptr, sometimes we need to search thru all available pending chunks, etc. it seemed best to do the multimap so i could grab the "equal range" thing. From what I've seen, I think the unordered multimap makes the most sense given that we search various ways for chunks/ptrs or for resources.

[MrBurmark]

Making this a nested container doesn't make it harder to get all the chunks for a given resource.
Using equal range is slightly simpler as it gives you a range directly range = multimap.equal_range(res).
Getting the range from the nested container is also simple iter = map.find(res); if (iter != map.end()) range = *iter.