# Performance core principles: 1. Unstored calculations **URL:** \ **Category:** NickLightbody's\ **Created:** [March 10, 2021, 1:06am UTC](https://the.fmsoup.org/t/performance-core-principles-1-unstored-calculations/1857 "2021-03-10T01:06:25Z")\ **Posts on this page:** 1\ **Showing post:** 30
**Author:** ![tonywhitelive](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/tonywhitelive/32/208_2.png) [@tonywhitelive](https://the.fmsoup.org/u/tonywhitelive)\ **Post date:** [March 13, 2021, 2:05pm UTC](https://the.fmsoup.org/t/performance-core-principles-1-unstored-calculations/1857/30 "2021-03-13T14:05:56Z")
Unstored calculation field are useful for providing the most recent order total in systems that are not fully locked down into a transactional design. On the other hand, unstored calculation fields can be expensive in some circumstances, for example displaying the most recent order total in a list view. One thing that can be done with expensive fields is to place them behind one of the following… - A “Hide object when" calculation - A Popover - An inactive panel (tab or slide) …and display only as needed. This “display only as needed” technique also works well for summary fields in a list view. There is only one correct answer on whether to use an unstored calculations field, a field set by script, or an auto-enter field… That answer is: “it depends” 😉 --- _[View the full topic](https://the.fmsoup.org/t/performance-core-principles-1-unstored-calculations/1857)._