assets_manager
assets_manager copied to clipboard
Iterate over loaded assets
It would be extremely useful to be able to iterate over loaded assets in an AssetCache (for example, to monitor memory usage or to detect unused assets to unload). I've scoured the docs and I'm not entirely sure whether there's any way to query for the set of loaded asset ids with associated asset types.
It is of course possible to achieve by wrapping the cache and tracking all loads and clears in the wrapper, but it would be far more ergonomic to have this as part of the AssetCache API.
Thanks for the suggestion! This is indeed something I'd like to add, and I've already thought about it a bit. I want to finish releasing version 0.13 first though (I should have only doc left at this point).
However, there is quite a design space here, so there are several questions for which I have no real answer, so additional input would be welcome!
Here are the several questions/trade-off I have:
- Iterator vs
Vecbased: obviously an iterator is best for flexibility and performance, but do to the internal locks would require manually building iterators and needunsafe, which is fine to me but not the ~most elegant~ easiest to maintain (generators would help there but I don't expect them to be stable soon).- In the
Veccase, more choices: return/take a mutableVec
- In the
- Typed/untyped version/both? This is specially important if the
Vecroute was taken - Consistency:
AssetCacheuses a shardedHashMapunder the hood, to reduce the cost of concurrent access. But this means that if one wants to have a fully consistent view of the cache, they must hold all the locks. - How it works with the new "fallbacks" API (still not sure about the name): does such
get_allfunction also gives assets from fallbacks? Doing so is less surprising but also strictly less powerful (is there even a use case for not doing so?).
I think I'm mostly settled on iterator, both typed and untyped versions, consistent, get assets from fallbacks. Feel free to give your opinion there!
to detect unused assets to unload
And side note: the API to remove assets was badly designed and will be removed in 0.13 in favor of the fallback API.
Thank you very much for the detailed response - personally I'd use the typed version, my primary use case would be monitor VRAM usage for textures for example - although given the rest of the API it would make sense for it to be paired with an untyped version.
I'm not sure precisely how the fallbacks thing is going to be structure like, but as long as it's at least somehow always possible to manually unload assets then it's fine by me.
I'm not really particularly worried by any questions of performance because tracking & unloading are only really a concern for assets that are Clone light IDs for heavy buffers like textures and audio that wouldn't go directly in the cache anyway. Consistency instead is very important of course