Tips & trick to decrease startup loading time in perspective

Is it possible to show some other content during resource load? or show my company logo instead of ignition’s GIF?

Old topic, but still relevant!!

Don’t use multi-level nested embedded views (EVs)!

-> Embedded View
   ->Embedded View
      ->Embedded View

I did a comparison of load times in 8.1.18 between using EVs with no nested EVs, and EVs which contains EVs that have at least one level of nested EV, and the results are incredible.

1st part (1.3s) - EVs with no nested EVs

-> Embedded View 1
-> Embedded View 2
-> Embedded View 3

2nd part (12.2s) - EVs with nested EVs that also have nested EVs - ignore the graphical crappiness… also it would actually be slightly longer than this as I’m missing one of the template Views

-> Embedded View 1
   ->Embedded View
      ->Embedded View
-> Embedded View 2
   ->Embedded View
      ->Embedded View

I’m still curious why IA weren’t able to “flatten” the main Views on the gateway before sending to the clients :thinking:
The main hurdle when I briefly looked at it was the inconsistent way of referencing parent level components (Perspective relative references to parent component properties), making it far more difficult to replace bindings in embedded views with their flattened versions :confused: certainly not a roadblock though. I’m curious what the roadblock(s) was/were?


It’s sad, because I really like using nested embedded views.
With them I can build views in a very modular way. Create “building blocks” that I use to make more complex views. It also helps keeping things to a certain standard, and making changes are easy because they are then updated throughout the project.

But I am for sure taking a performance hit, and like your video shows, the views load bit by bit which looks bad.

I know for performance I should ‘flatten’ the views, but I am holding out, hoping they would fix this issue

I actually thought this was the whole idea behind embedded views, to enable us to build modular views like this.

So I went ahead and added this to the ideas page, I hope the wording is fine.

1 Like

A problem I run into with embedded views is that the parameters stay stuck with the default parameter value, which is usually “value”.

I have to refresh the page when this happens (soemtimes more than once) to get the actually values to populate. This is a bigger problem when running a perspective Workstation client as oppose to a web browser client.

I thought about trying to write my own “flattener” code to go through all of the embedded views on a page and merge them into a single new version of the main view. The only time you can’t do this is if the view path is bound to something. The stumbling block I found was in converting the bindings in the embedded views, since you can’t just use parent.parent.custom.key; the best you can get is ../../../FlexContainer.custom.key but it requires you to know the name of the component, which is annoying. It’s not a show stopper, but it’s definitely annoying to handle!

Edit: I realise I said some of this already in my post above :slight_smile: time to go buy a walking frame I think…

You’re definitely right about embedded views making for cleaner design and standardisation across the project. Otherwise you’re forever copying and pasting components around, and if ever something needs to change or be added, you’re screwed and have to make the change in many places. CSS does help a little here though at least for the styling of the components, compared to if this was an issue in Vision

1 Like

Hrm. Can you check your loading order on these embedded views? We did a lot of work way back to make this faster, you just want to make sure your embedded views are set to load “with-parent” instead of “after-parent”

All of my embedded Views were all set to after-parent. I’ve changed them all (including all nested one as well) to with-parent and the results are below.
No nested EVs: 1,490ms
Nested EVs using with-parent: 12,120ms

Times calculated from gif frame durations.

No nested EVs
Perspective Tank Farm Load Time - Test 02p - No Nested EVs

Nested EVs using with-parent
Perspective Tank Farm Load Time - Test 02bp - Nested EVs load with-parent

Just note: the nested EV versions were designed for being displayed bigger than what they are on the page, hence they look all squished… although I do actually prefer the new look


Can you distill this test down into a project + memory tags that you could export and send to me?


Can do, that’s pretty much all I’m working with at the moment anyway. I’ll pm you later today


Just to add to this, I experience the same issue, Nested Embedded Views increase the loading Time dramatically, and it’s “choppy” like the GIF shows. That just doesn’t look super professional when presenting to clients. Hence one of my ideas on the forum was some sort of loading indicator, that way I could at least hide it behind something while it loads

Having a loading graphic for 12s though would probably feel even worse for a user though :sweat_smile: but hopefully Carl and and team can find some more efficiencies to be gained :crossed_fingers:

1 Like

Honestly even without nested embeded views it takes way to long.
We tried to make a warehouse with a whole bunch of instances, but it just took so long and idk why.
I made a custom module (which is basically the tempalte + the repeater) which is instant.


For Sure! My understanding of loading “With-Parent” was just that they will load at the same time, in other words you’ll see your Motor display appear, with all of it’s nested views, at the same time. Like it is waiting for all of it to load before displaying any of it, if that makes sense.

How many instances you have?
Do you use too many pipeline in your view too? If yes change them to svg.
If you use flex in container in your embedded view change them to xy coordinate
Can you share a gif video of your loading time?

For me as I have 150 complex embedded view the performance is good.
For simpler embedded view I can up to 500.

1 Like

This post has my gif in it:

I have 35 EVs on the page with a max nest level of 4
I don’t have any pipes
The symbol templates are a bit interesting… I created them as flex Views thinking that I would use flex for something later, and then embedded a coord container within it which ended up being the only component inside of the flex, with everything else inside the coord container. I’ve always been interested in comparing the load speed if I converted them all to coord Views instead.

In my experience it should be better if you use XY container so do it now.
And I always try to not go further than 2 level for repeating widget like this.

As I see your design it can be easily done with one level EV.
For the sake of the Object oriented design instead of using EV use CSS class Object oriented concept with python functions every where possible. So you can have a widget with one level of nesting.
For example I create a widget all in SVG and try to add different CSS binding by custom property and for event use function. So if I decide to change function I change CSS and python function.
Even I don’t wrap it in a view and directly use in my parent view.
This approach you can reach more than 2000 obj easily.

That’s all great information, I’ve always wondered how you managed to make your displays so performant.

I think though that the point is, you shouldn’t have to be forced into designing a particular way to gain 12 secs on load time. The load times should be similar for all technologies, and if there is some under the hood reasons why some containers are less performant, and you want to avoid that by optimizing that’s a choice you can make.

I think it’s generally understood that deeply nested EV’s will be less performant, how could they not be, but 12 seconds is a long time.

1 Like

Theyre not in Vision though, unless you are specifically talking about web tech

Not a fair comparison. Vision’s bindings and change events run in the client. Minimal gateway traffic to hold things up (unless you screw up with foreground callouts). And minimal per-client load on the gateway (also unless you screw up).

Vision is fundamentally faster than Perspective. Hopefully, a future with WebAssembly changes that.


Even in Vision, I bet there is a hit for using a template over not using it, jut not a noticeable one, unless of course the windows are all pre-compiled before being loaded to the client. . After all IA has had years to optimize Vision even after it was a mature product and perspective is still fairly new.

Either way, I was speaking specifically about Perspective. I wouldn’t expect there to be a noticeable difference between an EV loading in a Coordinate container as compared to an EV loading in a Flex Container.