Hi all, we are experiencing here massive CPU load whenever a step is using an interactive table widget, and even more so if there are several on a page. Have other people noticed the same behavior?
Are there particular config settings that may influence this adversely?
P.S: the max line number thing cannot be the root cause because this is also happening if disaply is limited to a single row.
Well, looks like it actually does make a difference… with 100 rows allowed in the widget it is killing the CPU… with only one it is behaving normally. Is this thing constantly redrawn??!
@Support: Does this thing cache at all? I would have expected if I link such a widget to a query that is filled with arguments that the result will be at least cached until a new updated result is received. But this is not what seems to happen under the hood. The player will keep querying the Tulip endpoints for each and every step and the UI is lagging as a result.
Can we please have a better description of what to do and what to not do with this widget and a better description of its behavior given its configuration?
Also… say the user selects a record in a step… the record is on page 2 of the widget. Then the user reloads the step… the widget returns to page 1 while the record on page 2 is still selected
Seb, I’m curious how you have the interactive table configured. My typical practice is to use a ‘Tulip Table’ (not Query) as a Datasource, and use Filters (be it static or dynamic), including ‘contains’ conditions on Text-type columns. Does your table use a large amount (> 3) of Linked Record columns? That could also cause performance issues at large scale. (Generally I avoid using the linked records feature.)
funny, this is exactly what I used to do until I ran into the performance issues. Having defined the queries beforehand seemed to reduce the load significantly.
I have stayed away from linking records too - our “development partner” started introducing them in some. However, this is certainly not the problem here for these queries.
If you ask me, this entire query and also interactive table widget thing is a terrible mess in its current form. It is convoluted and confusing. I can only imagine this is due to historic reasons as the platform went through its development cycle… if not, I would be very good to get a clear explanation of the underlying intent.
Have the same problem and the user complains about it. We have around 20 pages and user selects a record on page 11 and goes to a different step to view the info, and comes back to select a different record and it lands in first page although record from 11 page is selected. Did you find and solution to this issue. @Beth If you could share your thoughts on this ,how to resolve this problem ?
Hi
what’s about storing the table record id when leaving the step and re-setting this id when entering the step again?
For be more flexible you can proof which step the user comes from.
