Resource Managers

I’ve been looking for a fast, safe, memory efficient implementation of a basic resource manager that does a few things:

1. Uses handles instead of pointers

• Supports reference counting so resources can be shared and freed properly

• Doesn’t fragment the heap, but instead, allocates memory in contiguous chunks so all the data in a resource “pool” is local

• Is templated and simple

• Releases resource handles by pushing them onto the back of the list and getting available handles off the front of the list so that the most recently used handles stay in the handles list longest for best cache results.

 
 
Here are the ones I considered in my research.
A Simple Fast Resource Manager using C++ and STL (Ashic Mahtab, Zinat Wali)
Pros:
Uses STL and templates, very simple easy to understand, uses reference counting and handles.
Cons:
Uses strings for unique identifiers, pointers to resources are stored in std::vector, not the resources themselves, uses a stack for handles (push and pops off the front).
Gem: A Generic Handle-Based Resource Manager (Scott Bilas)
Pros:
Uses STL and templates, simple to understand, uses handles, stores resources not resource pointers.
Cons:
Uses strings for unique identifiers, does not have reference counting for handles (handle sharing), does not use a queue for handles.
Ogre 3D Resource Manager
Pros:
Is built to work with Ogre resources, supports shared resources and handles (reference counting), supports loading states and threaded loading of resources.
Cons:
Uses strings for unique identifiers, does not use a queue for handles, stores pointers to resources.
All these resource managers are great for managing resources loaded from files, which is why they all use a string as an identifier. None of them were designed with storing on-the-fly generated terrain data in mind.
I ended up starting with Ashic Mahtab and Zinat Wali’s manager code and modified it to use a std::deque for the handles, to use an unsigned long long as the unique identifier and to store the resources themselves and not resource pointers.
So after I coded that up I ran into some major problems:

1. The Ogre::VertexData class has its constructor set private so I couldn’t subclass it to easily make it a resource. The solution was to store a shared pointer to it instead, which means that I lose my resource memory locality.

• My vertices and blending vertices can be of variable size and my implementation was designed to store objects of known sizes (known at compile time). I could specialize the vertices manager class to handle this shortcoming, but I opted to just use a shared pointer instead.

 
 
Looks like I ended up basically storing pointers to resources instead of the resources so far!
The profile results show that I have brought the deletion time down from 251 microseconds average to about 5 microseconds average. Over-all the application update time and the _updateRenderQueue() function time seems to have decreased by at least half.
So I’m fairly happy with the results, the problem is that I’m still seeing spikes in the Ogre::Root::renderOneFrame(). The average time for that function is 4,000 microseconds, but the maximum time is around 40,000 microseconds.
In the future I will look into what is going on inside Ogre that is taking this time, but for now I’m going to continue on with my refactoring so this may be the last resource performance related post for a bit.