# Using variable with custom property in expression **URL:** \ **Category:** Ignition\ **Created:** [January 8, 2024, 6:42pm UTC](https://forum.inductiveautomation.com/t/using-variable-with-custom-property-in-expression/83936 "2024-01-08T18:42:56Z")\ **Posts on this page:** 1\ **Showing post:** 15
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 8, 2024, 8:37pm UTC](https://forum.inductiveautomation.com/t/using-variable-with-custom-property-in-expression/83936/15 "2024-01-08T20:37:23Z")
Bindings, throughout Ignition user interfaces, deliver values to session/view/window/page properties, custom or otherwise. All bindings are "set up" when a Perspective view or subview or Vision window or template is opened. The setup yields a java collection of objects tightly integrated with each other and with the target component. With the exception of any jython involved, everything is effectively pre-compiled during setup. Information flows from element to element in handsfuls of microseconds or less. While some bindings are "once and done", like expression bindings that yield constants, or non-polling queries, most bindings are intended to monitor some source of data and deliver updates through the binding. When a source reports a change, the binding completely re-executes. Transforms are a Perspective-only enhancement to bindings that create a chain of consecutive operations, with one result feeding the next, with the final operation's result providing the value for the target property. {Perspective desperately needed transforms because its complex components' architectures have a severe "impedance mismatch" with Ignition's internal object types, particularly dataset objects.} Transforms, for some unclear reason, introduce substantial overhead, on the order of high tens to low hundreds of microseconds. Jython, meanwhile, whether invoked in a binding by `runScript()` or by a script transform, adds considerable additional overhead. Again, tens to hundreds of microseconds per invocation, plus the performance penalty of an interpreted language. For some timing comparisons between script transforms and pure expressions for some common Perspective UI tasks, look at my Integration Toolkit module's topic for some of the testing shown there: > [@Automation Professionals' Integration Toolkit Module](https://forum.inductiveautomation.com/t/automation-professionals-integration-toolkit-module/74934/5): > > I have spent my holiday poking at this. Wanted to provide an efficient replacement for a common use of python transforms: Make a (Perspective) table that dynamically populates both .data and .columns from source dataset that isn't constrained to any particular structure or data types. In Vision, one can achieve this (mostly) by pre-populating the column attributes dataset with all of the possible column names your application might deliver. No such thing in Perspective. But a transform can … For some benchmarks on transform overhead versus runScript versus no script at all, check out this topic: > [@Tag binding or expression to read dynamic list of tags](https://forum.inductiveautomation.com/t/tag-binding-or-expression-to-read-dynamic-list-of-tags/76610/16): > > Collected some overhead stats. Added a sixth binding for comparison, and made them all trigger from a common reference. The new expression transform looks like this: nanoTime() - {value} It is notably faster than the other transforms. To make the recorder() run smoothly, I made a trigger timestamp with now({this.custom.pace}) and set pace to 200. Then I modified the transforms' first stages to look like this: asList( {this.custom.trigger}, nanoTime() )[1] The non-transform tests of run… --- _[View the full topic](https://forum.inductiveautomation.com/t/using-variable-with-custom-property-in-expression/83936)._