# Perspective Performance - View Bindings vs Expression Tags **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [May 19, 2024, 6:53pm UTC](https://forum.inductiveautomation.com/t/perspective-performance-view-bindings-vs-expression-tags/90595 "2024-05-19T18:53:17Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![cwells](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cwells/32/35042_2.png) [@cwells](https://forum.inductiveautomation.com/u/cwells)\ **Post date:** [May 19, 2024, 6:53pm UTC](https://forum.inductiveautomation.com/t/perspective-performance-view-bindings-vs-expression-tags/90595/1 "2024-05-19T18:53:17Z")
I am using CSS-based styles for shading graphical components on Perspective Views for device UDT's based on their status (like Running or Failed). In regards to performance, I have found that bindings on Views can create overhead (especially in more complex views). So, I am considering using expression tags instead when able to help reduce the processing load in the Views, putting it into the Gateway instead. Is this a viable path to follow? Example case of this: 1. Component on View has an expression binding to its styles.classes prop that references multiple parts of a UDT instance. 2. Instead of this, I would create an expression tag in the UDT that does that evaluation instead and bind that to the style.classes prop of the aforementioned component (i.e. Device.GraphicStyle) Thanks! ---
**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:** [May 19, 2024, 7:39pm UTC](https://forum.inductiveautomation.com/t/perspective-performance-view-bindings-vs-expression-tags/90595/2 "2024-05-19T19:39:52Z")
Everything in Perspective runs in the gateway. There's no "instead". If you have many UDT instances (more than Perspective clients that would execute that expression in a view), you might **increase** the total workload in the gateway, because those expression tags would execute even when no client was using them. ---
**Author:** ![cwells](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cwells/32/35042_2.png) [@cwells](https://forum.inductiveautomation.com/u/cwells)\ **Post date:** [May 19, 2024, 8:02pm UTC](https://forum.inductiveautomation.com/t/perspective-performance-view-bindings-vs-expression-tags/90595/3 "2024-05-19T20:02:40Z")
Interesting, so the client programs basically show the results of this processing? Does this mean that the performance of a client program is more dependent on both the speed of the connection to the gateway and the gateway's processing power and much less on its own processing power? ---
**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:** [May 19, 2024, 9:09pm UTC](https://forum.inductiveautomation.com/t/perspective-performance-view-bindings-vs-expression-tags/90595/4 "2024-05-19T21:09:26Z")
Yes, Perspective places significant load on the gateway--all customization of appearance and behavior runs in the gateway. Your original surmise would be correct for Vision, not Perspective. Perhaps you should read this topic (and the links within): > [@Microsoft Virtual Machine Suggestion](https://forum.inductiveautomation.com/t/microsoft-virtual-machine-suggestion/86787/5): > > After going through that sizing guide, I'd add another vCPU for every 4-8 Perspective clients (of pretty much any kind), a GB of gateway RAM for every 4-8 light-duty Perspective clients, and 2-4GB of gateway RAM for every heavy-duty Perspective client. "Light duty" would be single page Perspective apps running in Workstation, or Mobile, or single-tab browser sessions, displaying dashboards with real-time tags, up to an hour (-ish) of real-time trends, and pre-computed statistics for longer time…