Answer by Chris Krycho for Best approach to caching in Ember Octane

There are two categories of things here:

1. The two @cached decorators.
2. The caching primitives introduced via RFC 0566.

In the vast majority of Ember or Glimmer app or normal library code, you’ll just be using the decorator. You’d only ever really reach for the caching primitives if you were building some low-level library code yourself (not never, but not exactly common, either).

As for the @cached decorators, they have basically the same semantics. The tracked-toolbox version was research that fed into the the development of the primitive that Glimmer ships (and Ember uses), and so ember-cached-decorator-polyfill is implemented using the actual public API—polyfilling it via ember-cache-primitive-polyfill if necessary.

In terms of the performance characteristics, you don’t even actually need to think about it in terms of preventing re-renders: that’s not how the system works anyway. (See this blog post I wrote last year (2020) for a deep dive on how re-rendering gets scheduled in Ember and Glimmer using the autotracking concepts.) It’s also worth remembering that caching is not free! So it’s not as simple as “this thing costs something, so I should cache it”—the caching has to pay for itself to be worth it, and it costs both memory use and CPU time to create and to check caches.

With that caveat firmly in mind, I tend to think of “expense” here in the following categories:

• am I rendering this hundreds or thousands of times?
• does rendering this cause a long-running computation that will impact render (i.e. on the order of multiple milliseconds)
• does this trigger asynchronous behavior?
• (especially) does this trigger an API call?

In a lot of normal app code, the only getters you’ll really need to decorate with @cached are getters which produce API calls based on the components’ arguments. Since the getter will otherwise be invoked every time it is referenced, you will end up with multiple API calls, which can produce a situation where the apparent state in the UI flips back and forth as references to different promises resolve.