If something will not 'get' then the expectation is that a more costly "full load" or "upfront work" operation will be performed, but a 'set' will also happen so on next script load this won't be needed (at least, eventually, after things settle down across different access patterns).

The cache size is minimised, only required resources by the particular per-page/script are put there. Typically cache entries will be very small and voluminous, but predictable, hence why we don't just use individual fetches on a conventional cache layer. It is a disk vs CPU tradeoff. The intent is to approach performance as if each page/script were hand-coded to know its exact dependencies.

Some usage notes: Cached items should not be too volatile, although the cache is clever enough to not re-save if no real changes actually resulted from set/append operations; in other words the cache should quickly stabilise and not keep having to do writes You should not use this as an alternative to the persistent cache for caching everything that the persistent cache can already do; although sometimes it is good to do special batching operations (e.g. avoid repeating query patterns) that would already be separately optimised when the persistent cache was on We cannot always put cache stuff direct into smart cache as it may vary per-usergroup for example; anything in the cache really should be useful for all page loads, we do not want to have to load a great bloated smart cache on each page load; the above said, we will often say what is needed, then feed this in for doing bulk loads from the dedicated caches (e.g. saying which blocks to bulk load)