# Best practice defining logical functions in large scalable systems? **URL:** \ **Category:** Ignition\ **Tags:** python, scripting\ **Created:** [April 13, 2026, 9:14pm UTC](https://forum.inductiveautomation.com/t/best-practice-defining-logical-functions-in-large-scalable-systems/115054 "2026-04-13T21:14:31Z")\ **Posts on this page:** 1\ **Showing post:** 7
**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:** [April 14, 2026, 11:29pm UTC](https://forum.inductiveautomation.com/t/best-practice-defining-logical-functions-in-large-scalable-systems/115054/7 "2026-04-14T23:29:22Z")
> [@angus123](#): > > Is the idea here that the Python is being executed on the server side, then sends the results back to the client? How does this differ from the execution of logic defined via the tag binding interface? Both pay the same network transmission overhead, but because scripts are unbounded user-defined work we have to move them to a dedicated thread pool (paying thread transfer costs) plus synchronization penalties to wall-clock time. In unbounded pure-CPU workloads _without_ locking, Jython beats (pure) CPython, hands down. > [@angus123](#): > > Seems like there’s a range of plausible options. Per function definition, the "compilation" work happens lazily, once per project, regardless of how many sessions/pages/views are open in that project. The trigger to bust the cache is, if I remember correctly, **any** change to that project that affects Perspective itself or the scripting library. There's unavoidable overhead to marshal objects from their Java representation into a Jython representation and some other bookkeeping, but it's relatively cheap to call the same script repeatedly after it's been "compiled". > [@angus123](#): > > having numerous definitions for identical logic (60+ times in my case) This is almost certainly a smell about something else fundamental to your design, rather than a missing capability in Ignition. That is, this in particular sounds like an XY problem, even if I am personally on board for something like a [`lamdba`](https://support.microsoft.com/en-us/office/lambda-function-bd212d27-1cd1-4321-a34a-ccbf254b8b67) expression function. I've even [gone on record as such](https://forum.inductiveautomation.com/t/expression-management-best-practices-d-r-y/94662/2). > [@angus123](#): > > I’d like to understand as much as I can about Ignition’s compute model, especially how Python script execution compares to tag binding execution. I’m scouring the forum and internet for details; there are some posts comparing the efficiency of different bindings but haven’t found anything comprehensive yet. Any pointers to resources, or further detail here would be appreciated. Native bindings are always more efficient than expressions are always more efficient than scripts. If you can express something using bindings or expressions, do so - not only is it more performant, it's more easily maintained, because it's harder to bake bad habits into purely declarative logic, although with Phil's toolkit it's technically possible to do more complex operations via expressions. > [@angus123](#): > > I note there’s at least one guy on the internet who seems to be recommending this That OP's advice is paraphrased from advice typically given here on the forums, and only applies **once you have had to reach for scripting**. Again, there is nothing _wrong_ with scripting, and it's absolutely necessary for essentially every Ignition project. But it should not be your first resort. Once you **do** start using scripting, resist the siren's song of the "magic pushbutton". Extract _at least_ the core business logic into the project library, ideally with "pure" data inputs and outputs, totally separate from any logic tied to the UI. The maximalist take some (e.g. Phil) will espouse is to **never** write a script in the rest of the system that's longer than a one-line call to a project library script. This gives you, for one, vastly improved version control semantics and at least some hope of external testing. In my opinion, it's a little too strongly dogmatic, but Phil's also got a lot more real world experience with Ignition than I do, so take my advice with a grain of salt. Note that moving scripts to the project library has no real **execution** performance advantage nor drawback. --- _[View the full topic](https://forum.inductiveautomation.com/t/best-practice-defining-logical-functions-in-large-scalable-systems/115054)._