What is the most efficient way to access resources?

Question

I have a resource manager that loads and returns resources. Currently, I just return shared_ptrs for the resources I create, but I'm thinking about going over to using something like simple handles, whereby you get an ID you use to access the resource. The reasons are more explicit ownership, and also less overhead, rather than using smart_ptrs.

Are resource handles the most efficient way to access resources, should I stick with shared_ptrs or are there other alternatives?

The reason I am asking is that I was reading this article, which made me wonder if I should implement something like that, instead.

Answer 1

I disagree with Vittorio about not needing shared ownership of resources and, while I dislike the implementation of shared_ptr, it can be made to work just fine.

You want shared ownership because, of course, multiple game objects might be using the same resource. More importantly, if you have multiple levels and want to minimum level loading, you need some way to compute the union and intersection of resources needed by both.

One way to do this, which does require something more than just a shared_ptr, is to allow "loading" a level without resources and letting it take shared ownership of resources it needs. Then unload the old level, removing its ownership. Then, for any resource that still has ownership active but isn't loaded, load the resource.

For a resource A needed by levels 1 and 2, the reference count goes something like:

load level 1
ref=1
load A
load level 2
ref=2
unload level 1
ref=1

For a resource B used by only level 1, it goes like:

load level 1
ref=1
load B
load level 2
ref=1
unload level 1
ref=0 (removed)

And a resource C used by only level 2, it goes like:

load level 1
ref=0 (implicit, as no resource C exists)
load level 2
ref=1
unload level 1
load C

One method might be to have a layer of indirection. You store shared_ptr to a ResourceHolder. These holders are also in a list of some kind. When loading a level, you create and hold on to these ResourceHolder objects. They contain a unique_ptr to the actual resource (initially nullptr) and the path or other information needed to eventually load the item.

After loading the new level and unloading the old, you can then iterate through the list of live ResourceHolder objects, find any that have a nullptr handle to the actual resource, and then load it. When the shared_ptr to a ResourceHolder hits a ref count of 0 and unloads it, it also naturally frees the resource, and you should ensure that it removes itself from the list of live resources.

You can do much better than shared_ptr but it's a perfectly fine place to start to get up and running. Optimize it into something better later on once you have a working game.

Answer 2

No, they are not the most efficient way to access resources. The same Sean Middleditch who gave you an answer wrote an article "Dangers of std::shared_ptr" against using shared_ptr about one year later. You might consider using handles again. As he wrote himself:

Game engines have long supported this kind of borrowed reference using things like unique ID handles. Instead of storing a pointer (smart or otherwise) to an object, store a numeric ID instead (possibly wrapped in a templated type to ensure type safety).

Please review the section Efficiency in his article for more explanations on how to be much more efficient when using handles in contrast to shared_ptr.

For more advantages of IDs you can read the short Entity Component System Pattern article.