# Perspective Script Locations

**URL:** <https://forum.inductiveautomation.com/t/perspective-script-locations/54642>\
**Category:** Ignition\
**Tags:** perspective, ignition81, scripting\
**Created:** [January 4, 2022, 4:57pm UTC](https://forum.inductiveautomation.com/t/perspective-script-locations/54642 "2022-01-04T16:57:44Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![dominicfabiilli](https://avatars.discourse-cdn.com/v4/letter/d/c6cbf5/32.png) [@dominicfabiilli](https://forum.inductiveautomation.com/u/dominicfabiilli)\
**Post date:** [January 4, 2022, 4:57pm UTC](https://forum.inductiveautomation.com/t/perspective-script-locations/54642/1 "2022-01-04T16:57:44Z")

</div>

I am looking for advice on the best organization of scripts in Perspective.  
I know you can have scripts on component events, transforms, root container methods, in a scripting module, etc.  
Are there any differences in performance between running scripts in a session vs. calling a module?

And feel free to compare/contrast with an example:

- recipe entry using an editable table
- button scripts (currently) on the root container to execute: Save, Delete, Load, etc.

---

<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:** [January 4, 2022, 5:00pm UTC](https://forum.inductiveautomation.com/t/perspective-script-locations/54642/2 "2022-01-04T17:00:18Z")

</div>

Where the script is written does not have any (appreciable) performance implication. Where it is _called_ will.

For ease of maintenance, I would _strongly_ recommend writing as much as possible into project scripts.

---

<div class="post-metadata">

**Author:** ![dominicfabiilli](https://avatars.discourse-cdn.com/v4/letter/d/c6cbf5/32.png) [@dominicfabiilli](https://forum.inductiveautomation.com/u/dominicfabiilli)\
**Post date:** [January 4, 2022, 5:11pm UTC](https://forum.inductiveautomation.com/t/perspective-script-locations/54642/3 "2022-01-04T17:11:58Z")

</div>

ok thanks for the insight. another question:  
if my table has scripts for CellEdit and cell color changes, would you still recommend those be in a project script?  
Or would you expect those to execute better on the component itself?

---

<div class="post-metadata">

**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 4, 2022, 5:13pm UTC](https://forum.inductiveautomation.com/t/perspective-script-locations/54642/4 "2022-01-04T17:13:03Z")

</div>

> [@paul-griffith](#):
>
> written does not have any (appreciable) performance implication

Well, unless you are nesting function and/or class definitions. You _ **really** _ want to put those in script modules. Possibly only excepting clever use of closures for short function definitions.

---

<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:** [January 4, 2022, 6:23pm UTC](https://forum.inductiveautomation.com/t/perspective-script-locations/54642/5 "2022-01-04T18:23:54Z")

</div>

> [@dominicfabiilli](#):
>
> if my table has scripts for CellEdit and cell color changes, would you still recommend those be in a project script?

If it's truly something that only changes a single component, and you can't ever predict a future where the script could be re-used on another component, then it can reside on the local component.

What I meant in the first post is that there's very, very little overhead between a script transform running some code directly, or a script transform calling a function defined in a project script. In more exotic scenarios there _can_ be recompilation overhead, to Phil's point, but if the difference is just taking logic out of one place and putting it directly in a `def` in a project library, you should absolutely not worry about performance _based on the calling convention_.