Thanks for the test projects and demonstrations everyone. This is exactly what I was looking for in this thread. I think the strategy from here is to take this load-ahead concept and turn it into an option on components that embed views so that you can choose which ones load progressively and which ones load combined with their parent. I think in some circumstances you want to see the view put itself together before your eyes, and in other circumstances it’s better to hold off until sub-views are loaded before anything is displayed.
Set the loading mode of your views to ‘blocking’ and then check it out.
What I mean is the target of using embedded views are to create reusable and repetitive objects like native component for rapid development.
For example, I can create a button with embedded view with exact same functionality of the native perspective button component and both can do the same task. So here I can compare these two. OK?
But the loading of perspective button component is 10x times faster than the embedded view.
But views are generic and support many configurations. A component does its thing and only its thing, and can be optimized for that. Why would you expect a generic construct to perform as well? I think you are being totally unrealistic.
No I just miss and dream having embedded view like vision templates to be loaded fast. Even the new method have no good for this problem.
And for the record, there are other SCADA platfroms that has this in pure web and load very fast.
What I am trying to say is may be Perspective should
also introduce something else like template with some limited options but fast loading.
Ok, back to an update on what this thread is actually about:
Because of the mixed results in real-world applications, we’ve put in an option on the Embedded View and Flex repeater components to opt-in to this optimization. The default will leave projects loading like they did before, but you can have your embedded view load inline with it’s parent by changing the new loading.order property.
We’re still analyzing the projects you’ve sent in to find more opportunities for improvement.
2 Likes
Hi Carl,
Is there any demo form your side that show the new optimization in action as some short video?
May be there is some thing I did wrong in my project that this new optimization doesn’t work for me.
For example as you see my project include a lot of small embedded view of P&ID devices.
Each include some text and SVG graphic with a lot of expression binding.
Yes, I can put together a demo. I’m making some further optimizations based on the feedback I’ve gotten here, stay tuned…
6 Likes
Okay everyone, thanks for your patience. I have identified why this “optimization” ended up making many of your projects slower where it had made my test project faster.
The difference had to do with breadth vs depth. The optimization helps the most on view configurations that are very deep - many layers down of embedded views. The projects that you’ve sent me were instead very shallow but quite broad - dozens or hundreds of views directly loaded underneath the first layer of the mounted view. In this style of configuration, the new loading strategy (which now called loading.order: with-parent) exposed a different inefficiency that we have now corrected. Now that both strategies are able to operate efficiently, the results are … still mixed, to be honest But don’t despair!
View loading performance is a complex topic, but the short story is: both strategies are now faster than they were before. In very deep nested view configurations, the with-parent strategy tends to be significantly faster. In broad configurations, the results are mostly a wash - they’re about the same speed. In some configurations, after-parent still wins by a hair. Which one you will want to use will come down to preference about how you like your views to feel as they load: progressively or all at once.
Furthermore, which one “feels” faster overall has a lot to do with the way property state is calculated and propagated to the views. While loading all the views at once is more efficient for the browser, it also delays the startup of the back-end of the view (e.g. bindings) until all the views are loaded. In some cases, this can make with-parent feel slower, because when using after-parent even if it takes longer to load all the views, the topmost layers of views get started up sooner, and so their bindings get a head start on evaluating even as deeper views are still loading.
It is this area of initial binding execution and configuration state that we will be delving into for the next round of optimizations. But in the meantime, you can observe these side-by-side comparisons of the latest performance of with-parent vs after-parent in some test views.
5 Likes
Are these footage are from 8.1.5-rc1?
Not quite. They include two minor but impactful additional improvements that will be in 8.1.5-final
1 Like
I am using embedded views for six columns in a table. Everything is pretty smooth unless the table.props.data binding returns a large number of rows. When that happens, you can watch each row's embedded views load and fill out. It is slow loading the embedded view and displaying the value, but the rest of the table's cells load almost immediately. Is there any way that I can speed up the loading process of the embedded column views? Are there any plans to make loading embedded views in this scenario faster?
Use pagination.
If you use flex as root for your embedded view change it to coordinate.
2 Likes