We have 130 station for which we are reading the status from kepware. We created a mashup in which we are showing the status and binded it to the collection widget. And sending the station id dynamically. When mashup is loaded (in which collection widget present) it takes time to load the 130 stations instead of bringing it up quickly. And whenever the resolution is changed it becomes blank and then loads the stations. Why is the collection widget so slow? Is there any way to improve the performance of collection widget?
Is there any alternative widget which can be used instead of collection widget?
@svisveswaraiya Collection widget is itself is a heavy widget to use. Here i want to understand your case.
I have encountered performance issue with collection widget in the past where customer were using nested collection also few more widgets in that collection.
It would be great if you can give more information on this use case.
How we can improve nested collection performance?
Service is executing less than 5 seconds but nested collection widget rendering taking so much time.
Is there any best practices?
Did you try using ItemLoadBehavior property to either use Load/Unload or LoadAll. I think Load/Unload will have ease on loading only the content which is visible on the UI at that time. More you scroll down, then it will start showing the below content. Also uncheck PlaysIntroAnimation property.
If it is a very simple mashup within each mashup pls try advanced grid with images link ,checkbox etc to display the data from 130 stations
if that is not possible you could try to reduce the no of mashups shown in the screen and implement pagination
Contrary to what people are saying here, no, the collection is not a heavy widget. It's what you put in the mashup that gets used by the it that counts. Don't use new widgets, try to use legacy ones, we have seen 40-60% improvement only on that. Don't use widgets that change the DOM, like the value display. The collection basically repeats a portion of code, if you change that code, the Cell has to re-render which takes up time, and screws with performance. Try to keep your collection mashup as simple as possible. If you're using too many widgets in the mashup, you might want to rethink how the app works. Browsers can do so much...
Hi Gabriel - We continually run performance tests and optimize our latest widget set. Here is an example of a test we run and the result:
Widget type and numbers per page
100 Value display
500 buttons, checkbox, toggle button
In the past, we've responded to customer feedback and field issues. For example, using value display inside collection view, which we solved for in release 9.1. If there are additional use cases that we should be aware of where performance is an issue, please let us know through tech support including detailed reproduction information.
Hi @RachelMc ,
Sorry for the VERY late reply. The value display there might not be a fair test. We usually use value display when we want to style that widget based on some value with a state definition. So with a random test of values from 1-100 and a state definition for 0-25, 26-50, 51-75, 76-100, try to style the text differently(font size, weight, background, color). Then tell me the result. Because the value display usually replaces that block of code which requires a redraw from the browser.
If the collection widget you're using requires scroll then it's not really 100 Value display. Collection widget only draws a few cells and reuses them when you scroll. Can you share some entities from your test? Thanks!
Hi @GabrielB - We did the same test you described, and we did not see any performance issues, We tried a few different variations and still didn't find an issue. Would it be possible for you to share some of your entities with us? We could also jump on a call to go through your use case more in depth, especially in the case of collection, to get at the root of the issue you're seeing.