# Performance core principles: 1. Unstored calculations **URL:** https://the.fmsoup.org/t/performance-core-principles-1-unstored-calculations/1857 **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:** 6
### Author: ![Torsten](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/torsten/32/1574_2.png) [@Torsten](https://the.fmsoup.org/u/Torsten) #### Post date: [March 8, 2021, 6:08pm UTC](https://the.fmsoup.org/t/performance-core-principles-1-unstored-calculations/1857/6 "2021-03-08T18:08:07Z")
@nicklightbody had the good idea of delving deeper into concepts and implementation strategies that enable high-performance solutions. I am opening a separate thread for the calculation field topic, but consider @nicklightbody as the [OP](https://the.fmsoup.org/t/lets-deep-dive-and-explore-performance/1833). We all started out making extensive use of (unstored) calculation fields because they come in handy and we get a quick result. And we all made the experience that what works well for a couple or even a few hundred records, will not necessarily perform well with large data sets - specially when relationships are involved. I admit to still using them in solutions with larger data sets, but not the way I did when starting developing in FM. Today, I am using them for displaying up-to-date data on layouts and there only for the parent table and/or a few related records in portals. A good example is a date/days calculation that involves current date or time. They are not used for generating reports on larger data sets, as this surely slows things down to a crawl. So (unstored) calculations can be useful and be used as long as we are aware of what the limits of application are. How do you take advantage of (unstored) calculation fields? --- _[View the full topic](https://the.fmsoup.org/t/performance-core-principles-1-unstored-calculations/1857)._