Hi everyone,
I have a element subpage with many displayed parameters.
(56 standalone parameters, 1 table)
In order to see all the parameters, there's a need to scroll through the subpage.
However whenever I select this subpage and scroll, I noticed a substantial lag in the scroll. The lag also happens when I open the subpage from it's page button.
Is there a max amount of parameters we can display in a page?
Would the page's load time be impacted when a table is placed in a single column page vs 2 column page?
Hi Khoo Chee Yang,
Nice question!
I can already share that Cube will indeed lazy load parameters as we open the page they belong to. This means that, indeed, the more parameters a page contains, the longer it will take to load the data.
Other than that, I wonder if it makes sense in the first place to have that many parameters on the same page. Indeed, even without considering the performance side of things, having a page cluttered with too many parameters will not be that user-friendly. Isn't there a way for you to nicely split those parameters into 2 or more meaningful categories so you can split them in 2 or more appropriate pages?
Coming back to the performance side of it, I'm wondering what the impact of a standalone parameter vs a table is. Because while 56 standalone parameters sounds like a lot (as in, not that usual to display that many on a page), a single table parameter will typically contain many more cells and still load pretty fast. So for some reasons, it feels from your question like standalone parameters have more weight/impact than a table cell. Hopefully some colleagues can shed some lights on that part.
As a follow-up question, how big is the table added to that page? How many cells are we talking about? Could it be that the load is mostly coming from that table alone and that the 56 standalone parameters are just fine?
regards,
Hi Khoo Chee Yang,
Thank you for the additionaly information.
A table of 154 cells is definitely not to be considered a big table, it's in fact a pretty small one.
So yes, I would say that next step is to report this as an issue through UOSA. If you could make sure to provide test connector(s) to reproduce the issue, a link to this Q&A thread, etc into the ticket.
More info on how to create such UOSA ticket can be found here: https://docs.dataminer.services/dataminer/Professional_services/Support_Services/User_Operations.Support.html
regards,
Alright will do, thanks for looking into this!
Hi Simon, thanks for replying!
We are indeed dealing with a problem where we have too much shown on a page. I do agree that the proper fix would be split up those parameters into other pages.
The table that was added has 22 columns.
It's a rack cooling table where every row represents a rack cooling board.
The number of rack cooling boards on the device are fixed at 7, so we are looking at 7 rows always.
Total cell count: 7 * 22 = 154 cells (I'm not sure if 154 cells is considered big)
I did some experiments examining how the removal of params will lead to the lag disappearing.
Version reporting issues
-> lags
Version with shrinked table
-> The lag disappeared when I made 4 read columns no longer displayed on table.
Version with removed standalone parameters
-> The lag disappeared when I made 3 standalone read parameters no longer displayed on the page.
Based off the above results, it seems like a standalone parameter has more load compared to a column parameter with 7 cells (7 rows in table).
I do wish to know how much load a standalone parameter has on SLElement compared to a table cell.
It will also be nice to have some sort of guideline on the max number of standalone params to have displayed on a page as it is not listed anywhere (checklist, docs etc) as of now.
I also wonder why is it that lazy loading of the page results in a cube freeze?
Ideally, when lazy loading occurs, cube shouldn't freeze. Instead we should just wait for data to be loaded into the parameters.
Kind Regards