Search Unity

  1. New Unity Live Help updates. Check them out here!

    Dismiss Notice

Feedback Touch cahce of existing (live) asset for more effective caching

Discussion in 'Unity Accelerator' started by Kichang-Kim, Mar 3, 2020.

  1. Kichang-Kim

    Kichang-Kim

    Joined:
    Oct 19, 2010
    Posts:
    465
    Hi. I think that current cache eviction policy of unity accelerator is LRU. Then Its timestamp is updated when actual asset cache is requested or updated.

    The problem is that this timestamp update method does not work well for "live" assets. In example, project AAA has lots of FBX file and some textures. And textures are updated very frequently so cache server is full of textures'cache. Then, cache of FBX files are evicted because it is not used recently.

    But, FBX files are live in project and new setup of project AAA takes very long time because cache server has only caches for textures (more badly, most of them are unused anymore).

    So Unity editor and Unity accelerator should have something method for updating timestamp of "live" assets (in other word, existing or trackable assets) I think. It may be similar to the policy of git lfs caching algorithm.

    Thanks.
     
  2. gregoryh_unity

    gregoryh_unity

    Unity Technologies

    Joined:
    Oct 1, 2018
    Posts:
    5
    Hello! Thanks for the feedback. The current eviction policy is by an internal sorted eviction key retention/rank/access/namespace/key. The retention/rank isn't currently important (future features maybe) but the rest .../access/... is what you say: access = most recent write or read of the key.

    We're going to change to .../access/creation/... and having writes have an access of 0. So the first to be evicted would be the oldest written value that was never read.

    So, when any value is read it would be bumped to the last to be evicted. The possible downside to this is if code writes a key/value once, reads it once, then never again. To fix that we'd need to track accesses and only bump the access time when x reads happen within y seconds -- something we'd rather avoid if we can. So for now we'll just implement what was described in the previous paragraph.

    I'll update this thread when the updated eviction policy has been released, and thanks again for the feedback.
     
    Kichang-Kim likes this.
unityunity