# Binding Transforms Best Practices

**URL:** <https://forum.inductiveautomation.com/t/binding-transforms-best-practices/24899>\
**Category:** Ignition\
**Tags:** ignition80\
**Created:** [May 10, 2019, 6:52pm UTC](https://forum.inductiveautomation.com/t/binding-transforms-best-practices/24899 "2019-05-10T18:52:07Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [May 10, 2019, 7:40pm UTC](https://forum.inductiveautomation.com/t/binding-transforms-best-practices/24899/2 "2019-05-10T19:40:46Z")

</div>

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 do cache these, but it still has to happen) and then finally execute that using the interpreter and handle the result value.

That said - unless you have literally thousands of transforms on a page, you’re much more likely to notice I/O bottlenecks (tag reads, database queries, HTTP traffic) than transform related slowdown problems.

If you, and anyone who has to maintain the project after you, are more comfortable using scripts, then by all means do so. Avoiding using the tool you are best with would definitely fall into premature optimization, in my opinion.

---

_[View the full topic](https://forum.inductiveautomation.com/t/binding-transforms-best-practices/24899)._
