Skip to main content

Scripting Performance & Scale

About 4 minscriptingworkspace

Scripting Performance & Scale

Scripts in IOTA are powerful but can degrade performance if not managed carefully. This page covers the common traps, practical guidelines, and known limitations for builders working on complex or large-scale deployments.

Data source latency looks like a script problem

Before tuning scripts, confirm where the slowness actually is. Open the Driver Log (≡ menu → Driver Log) and look for requests taking more than a second. If data requests are slow, the bottleneck is in the data source — not the script. See Diagnosing Slow Loads for source-specific guidance before making any script changes.

Global Scripts vs Component Scripts

Global scripts are attached to the view and execute once after all components have loaded. They have access to all components and are the right place for cross-component coordination — synchronizing a dropdown with a navigation event, or applying consistent formatting across a group of charts.

Component scripts (onCreate, onChange, onData, onTick, onFocus, onDblClick, onHover) are attached to one component and fire only when that component's state changes. They are scoped and predictable.

Prefer component scripts over global scripts whenever the logic is specific to one component. Use global scripts only for logic that genuinely needs to coordinate across multiple components. A global script that re-runs complex logic on every GTC tick — rather than limiting itself to cross-component coordination — is the most common source of scripting-related slowdowns.

Common Performance Traps

GTC-triggered loops

A global script that calls callDriver, updates channel data, or re-renders multiple components on every GTC change will generate a burst of requests every time the user adjusts the time range. Wrap GTC callbacks with a debounce of 50–100ms to reduce the number of executions during slider scrubbing.

Too many concurrent Line Charts

Each Line Chart runs a continuous rendering loop. On a display with four or more charts, these loops compete for the browser's main thread and can cause the page to become unresponsive. Mitigation options:

  • Hide charts that are not in the viewport using conditional visibility
  • Split a dense chart display into multiple views with navigation between them
  • Use the Engineering View to keep construction elements out of the viewer's rendering path

Slow data sources loaded on page open

SQL databases, analytics platforms like Seeq, and cloud sources (Azure Data Explorer, Snowflake, Databricks) have much higher query latency than a local historian. If a global script loads data from these sources at initialization, the entire display stalls until the slowest source responds. Load slow sources on demand — triggered by user interaction — rather than on page open.

Large global scripts across many views

IOTA does not support bulk script assignment. A global script must be added to each view individually. For deployments with hundreds of views, a change to shared logic requires manually opening each view.

Mitigate this by keeping global scripts minimal and moving reusable logic into component scripts. Bulk script assignment across views is a known limitation planned to be addressed in a future release.

When Performance Is a Data Source Problem

Script and component tuning can only go so far — some slowness originates in the data source and cannot be solved from inside IOTA. Understanding which layer is slow is essential before changing any script logic.

For source-specific diagnostic guidance — including PI AF attribute issues, Seeq cold starts and thread pool saturation, SQL and cloud analytics indexing, and infrastructure latency — see Troubleshooting → Diagnosing Slow Loads.

PI System Calculations (Performance Equations)

PI System Calculations run server-side on the PI Data Archive. A complex Performance Equation formula — or a formula applied across a large time window with high-density data — adds latency proportional to formula complexity and the number of raw events evaluated. This latency compounds when multiple Line Chart channels each use a different PI calculation.

If a display with PI calculations loads slower than an equivalent display with raw PI tags, the PI Server is the bottleneck. Check the formula complexity and the requested time range against the tag's archive density.

Guidelines

  • Confirm the slow layer first: use the Driver Log to check whether data requests are taking more than a second before touching scripts. See Diagnosing Slow Loads if the bottleneck is in the data source.
  • Wrap GTC-triggered callbacks in a debounce (50–100ms).
  • Avoid calling callDriver inside a loop or in response to every component event.
  • Load slow sources (Seeq, SQL, cloud analytics) on demand rather than at page open.
  • Test multi-source displays with realistic time ranges before production. A 24-hour range against a SQL source that takes 3 seconds per query will stall the display on load.
  • Limit global scripts to cross-component coordination logic.
  • When a display starts running slowly, remove the global script temporarily and reload — this isolates whether the script is the cause. If performance is the same without the script, the data source is the bottleneck.
  • For view templates that need consistent behavior across assets, use component scripts and asset training rather than a global script that reconstructs component state on each load.

Managing Scripts at Scale

There is currently no bulk script manager in IOTA. For large deployments:

  • Prefer component scripts and templated components over view-level global scripts
  • Document which views carry which global scripts in an external reference (a spreadsheet or your project documentation)
  • Use descriptive names for global script variables and functions so the intent is clear when revisited months later
  • Raise a feature request with the IOTA team for bulk script management tooling

Warning

A display combining heavy scripting with multiple slow data sources (Seeq, SQL, cloud analytics) can push browser RAM above 1 GB in a single tab. If viewers report tab crashes or freezing, check the Driver Log first — if data requests are slow, see Diagnosing Slow Loads. If data requests are fast, remove the global script temporarily to isolate whether script execution is the cause.

What's Next

With your displays built, scripted, and tuned for performance, the last step is getting them in front of the people who need them. The next page covers publishing, folder access, and the view ownership model. Continue to Sharing Displays.

IOTASoftware Licensed | Copyright © 2021-present