I’m working with some colleagues on a project which the clients would like optimized, as they feels some things are too slow.
One of my colleagues has suggested that we should cut down on the use of formula fields by moving the logic into either workflows or triggers, so they won’t be reevaluated so often.
While I imagine there is a performance cost to reevaluating the formulas (especially if we don’t expect them to change often), it seems untidy to me that we should move the logic out of the fields into a longer, less obvious, process… and I’m not entirely convinced the gains will be significant.
Does anyone have any knowledge or experience to support or refute the idea?
Formula fields are determined at read time, as they are not stored in the database. Which can make things slow down when reading the records in some cases. There is a great blog post here on the topic, which does indeed recognise that developers often maintained formula field type information in physical fields calculated at write time in order to avoid this. The blog mentions that while this is still possible, since Winter’13 you can now consider asking support to apply indexing to the formula fields.
To get around the pre-Summer ’12 index limitations involving formula fields, many customers created workarounds. For example, you might have created triggers or workflow rules to store formula field values in a separate custom field that you could index, and then built queries that filtered using the custom field instead of the formula field. That strategy works, but it requires overhead and is not intuitive to developers.
Since the Winter ’13 release, you have been able to contact salesforce.com Customer Support to create a custom index on a formula field, provided that the function that defines the formula field is deterministic.
Read more here. At the end of the day always make optimisation improvements based on as much objective and ideally measurable (hence comparable) evidence as you can find.