# Building for Performance **URL:** \ **Category:** Ignition\ **Tags:** ignition81, perspective\ **Created:** [March 15, 2023, 9:53am UTC](https://forum.inductiveautomation.com/t/building-for-performance/71082 "2023-03-15T09:53:12Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [March 15, 2023, 2:11pm UTC](https://forum.inductiveautomation.com/t/building-for-performance/71082/3 "2023-03-15T14:11:43Z")
In this example, #3 is the most performant, though it could be argued that the performance gain in this instance would be negligible. Anytime you add an additional processing step you add latency. In general for the best performance I follow these guidelines: - If you can achieve what you want with a binding, use a binding. - Always use the binding type that is the most direct. (e.g. if all you need is a binding to a property use a property binding, not an expression binding.) - Given the choice between an expression and a script, use an expression. - Minimize the amount of data that must travel between gateway and client. - Minimize the amount of duplicate data repeatedly sucked out of your database (caching, etc). - Minimize the amount of duplicate calculations done for multiple points of use - When scripting choose a Java import over a python import if available - When scripting use the NetBeans shortcuts where applicable - Keep global script data in top level variables in a project script rather than recreating it - When scripting tag reads and writes always combine them to as few function calls as possible. I've picked these up from various posts on the forum over time. I keep a running list for quick reference (particularly for training) and add little golden nuggets when I see them. A couple of links for references. @paul-griffith's assumptions about the performance of different binding transforms > [@Binding Transforms Best Practices](https://forum.inductiveautomation.com/t/binding-transforms-best-practices/24899/2): > > Seat of the pants answer with no performance testing to back it up: native transforms (ie, mapping) will be faster than expression transforms will be faster than script transforms “Native” transforms are executing as direct Java code in and out. Expressions have to be parsed and calculated in steps, so there’s more lookups and variable timing involved. Scripts will almost certainly be the slowest - we have to either grab or create a Python interpreter, compile the function you provide (we … > [@General Binding Efficiency Ranking](https://forum.inductiveautomation.com/t/general-binding-efficiency-ranking/67686/3): > > Without actually doing the research to back it up: Format \> Map \> Expression \> Script, in terms of performance. Again, caveats as Phil noted, including the fact that map transforms can have expressions in the output. NetBeans shortcuts are faster than the long form. For example if getting the column names from a dataset object use `dataset.columnNames` rather than `dataset.getColumnNames()` > [@Looking for advice on dynamic Pen creation in the Power Chart component](https://forum.inductiveautomation.com/t/looking-for-advice-on-dynamic-pen-creation-in-the-power-chart-component/67751/3): > > Yes, if scripting anyways. If avoiding scripting to avoid its startup penalty, the lookup() expression function with a dataset tag is a performant option. No, this: pyr['value'].quality.good not pyr['value'].quality.good Use the NetBeans shortcuts everywhere applicable, not just .value or .quality, as they run faster and are more readable. Even better is to only check .good in the if clause and use an else: clause for not good. > [@How do you increase performance for clients?](https://forum.inductiveautomation.com/t/how-do-you-increase-performance-for-clients/62703/2): > > Vision or Perspective? In general, though: Minimize the amount of data that must travel between gateway and client. Minimize the amount of duplicate data repeatedly sucked out of your database (caching, etc). Minimize the amount of duplicate calculations done for multiple points of use (less important in Vision clients). --- _[View the full topic](https://forum.inductiveautomation.com/t/building-for-performance/71082)._