Here is late night problem that keeps me awake ;)

In our offline mobile app we have a performance issue when dealing with the huge table on screen. data is fetched using simple aggregates to get reformatted data from local entities.

It is nested list with grouping. If all grouped are open the total visible cells count is around 15000. It is no fancy data or styling - one value per cell + background color depending on math calculation of cell input parameters. 

I've tried to control maximum cells visible by allowing only one group expand at a time, but this is a temporary solution as adding elements to the table will at some point bring problem back.

Screen memory usage in chrome varies between 300MB (all groups are collapsed) and 3GB (all groups are expanded and there are 15000 cells on display). Page size is from 2 to 30 MB if saved to disk. I've tried to reduce this by using shorter names for blocks, classes and flow that the cell block is (as multiplying looooong class name to 15000 makes difference, or not?). So at some point on device it just crushes the app. On desktop screen is more or less usable but on device like iPad it just sticks at some point and some times there is significant delay on rendering values for some cells (not sequential and does not related to data retrieval)

There is a onClick action that triggers an event to  pass information to higher hierarchical elements on each cell and some basic math calculation to determine cell color. Can this be a problem and if yes what is the alternative (custom js listener per class for example)?

So there are few questions raised by this problem:
- is there a known flow that leads to this extended memory usage?
- what is the best practice for rendering complex tables in OutSystems mobile apps?
- any way to have "infinite" lists (tables) that are using fixed number of elements (currently visible in screen) and then repopulates them with new data on scroll (like pagination and lazy loading but without that stops in between). Use case is imagine table or very long list where 10 element are visible on screen and user should have possibility to scroll fast to the last element using momentum scrolling effect.

I will appreciate any advise or thoughts on this matter. Thank you in advance.


- If you keep the lists as local variables, it will increase your viewstate enormously.

- Don't use large tables :P

- What I have done, is doing the calculations on the screen itself with basic jquery,Simply store the changes in the database.

-You might want to think if you should use divs instead of tables..

tables got a big issue that it needs to know all before rendering, while divss are rendered as they come by so to speak.


Thank you very much for advice.

We use divs to form the table. 

Regarding local variables - good point. Will remove all local variables with Aggregates results. Btw is there a way to see view state size in chrome dev tools?

Do you know if having link to client action on each cell is affecting performance or it is managed smart way having only one function? 

Hi Mykola,

this comes like, 2 years late but you can check the view state by using this chrome extension. I'm not in any way associated with the creator but I find this tool very useful while developing my applications.