Loading Performance Problems with Perspective bindings

Hi!
I'm having performance problems with some binding on some gauges.

I belive that the code that is causing my problems is this one:

	color = system.util.jsonDecode(value.get("color"))
	low = color[0]
	med = color[1]
	good = color[2]

	current = value.get("value")

	if current < int(med.keys()[0]):
		return low.values()[0]
	elif current < int(good.keys()[0]):
		return med.values()[0]
	else:
		return good.values()[0]

The value is a expression structure that comes from 2 custom properties that both are indirect tag paths.
The color tag is an array like this: [{"0":"#cf7911"},{"75":"#ffff00"},{"90":"#58d68d"}].
The value tag is simply a integer value (0-100).

When removing this 4 gauges the page loads in 1-2 seconds, if not removed, it takes about 4-5 seconds.

How could I improve this?
Any help is appreciatted.

If you wanna know about the objective of the code here.

Numbers are not valid keys for JSON/JS, I would restructure the object like this

[
  {
    "value": 0,
    "color": "#cf7911"
  },
  {
    "value": 75,
    "color": "#ffff00"
  },
  {
    "value": 90,
    "color": "#58d68d"
  }
]

You can use an expression instead of firing up a script

case(True,
	{this.props.value} >= {this.custom.colors[2].value}, {this.custom.colors[2].color},
	{this.props.value} >= {this.custom.colors[1].value}, {this.custom.colors[1].color},
	{this.custom.colors[0].color}
)
2 Likes

Clever case statement. Good general rule of thumb as @dkhayes117 is hinting at here -expressions are always preferably for speed/effeciency over scripting whenever feasible.

1 Like

Do not use system.util.jsonDecode() in performance critical scripts. You should use a Document tag, not a string. Then the actual binding can be an expression instead of a script.

1 Like

Seems to be that the problem was "bigger" than we thought... Is not the script, static simple gauges take about 5 seconds to load.

Help for the feedback guys!
But I had to open a ticket to get it resolved.

The static gauges are a bit notorious for being slow, to the point that many use a script transform on an embedded svg instead.

I would recommend making the script part of the transform a function in the project library for easy re-use(and to avoid having to import inside of a function).

1 Like

For what it's worth, I would probably do this differently these days. Utilizing more CSS. Probably wouldn't even need a script transform. I can look into that if needed/wanted.

Something more along the lines of what I did in this thread.

1 Like