Solved: App very slow on first row select

Phil_Waite · 02-04-2020 07:43 AM

Hi,

The first row selected after the app has been synced is very slow to open aproxx 7 - 10 seconds. After that it is fine.

It is a slice of the main table that has 19K rows. It wasn’t this slow before and I have reduced the number of rows. I also tried removing the expression for the slice as I put it in the
Any suggestions?

thanks

Phil

Phil_Waite

Hi,

I have solved the slowness of my app. I had a problem with the fact that there were so many detail views that all had to be edited with “columns to include” everytime on of them was changed to make them all look the same.

I posted about this and someone suggested making an a action that takes the user to one detail view. Then make that action the event on row selection for all of the views. Problem solved - the user is always takent to the same detail view no matter what view they are accessing the dat from.

This is where the slowness problem came in. The single detail view that I randomly chose to be the one used for everything was “For This Data” set to a slice of the main table not just the main table itself.

The Slice happened to have this expression used for a running sheet where the length of it and delay isn’t a big issue as it’s used infrequently. This was slowing down the app as it was calculating this slice each time.

ISNOTBLANK( FILTER( “Orders”, AND( ([Outlet No] = [_THISROW].[Outlet No]), ( [Delivery Date] = LOOKUP(
[Unique ID], “Running Sheet 2”, “Unique ID”, “Delivery Date” ) ), [Order Status Calc]=“Open”,

IN([Route] ,(LOOKUP( [Unique ID], “Running Sheet 2”, “Unique ID”, “Route” )))
) ) )

This is also relevant to some other posts I made regarding speed, mutiple detail views and how to slim down to one.

Thanks

Phil

View solution in original post

MultiTech

19K is where it starts to get hard.

Many things to consider when troubleshooting the slowness of an app. Have you taken a look at the performance profile?

To give you a little more to chew on, it sounds like what you’re saying is that when someone is trying to OPEN the record? Do you mean when the form is opening there’s a pause or delay?

Phil_Waite

Hi,

Thank you. I looked at the link and I think that the number of table that I have (37) and the references between then is what is slowing it down. Yes when the user clicks on a row in the main table it take about 10 seconds to go to the detail view for that row. This is on the first time after a sync. after that it is fine. I think I have some unused references and expressions that can be removed which should help.

Thanks

Phil

Phil_Waite

Hi,

I have solved the slowness of my app. I had a problem with the fact that there were so many detail views that all had to be edited with “columns to include” everytime on of them was changed to make them all look the same.

I posted about this and someone suggested making an a action that takes the user to one detail view. Then make that action the event on row selection for all of the views. Problem solved - the user is always takent to the same detail view no matter what view they are accessing the dat from.

This is where the slowness problem came in. The single detail view that I randomly chose to be the one used for everything was “For This Data” set to a slice of the main table not just the main table itself.

The Slice happened to have this expression used for a running sheet where the length of it and delay isn’t a big issue as it’s used infrequently. This was slowing down the app as it was calculating this slice each time.

ISNOTBLANK( FILTER( “Orders”, AND( ([Outlet No] = [_THISROW].[Outlet No]), ( [Delivery Date] = LOOKUP(
[Unique ID], “Running Sheet 2”, “Unique ID”, “Delivery Date” ) ), [Order Status Calc]=“Open”,

IN([Route] ,(LOOKUP( [Unique ID], “Running Sheet 2”, “Unique ID”, “Route” )))
) ) )

This is also relevant to some other posts I made regarding speed, mutiple detail views and how to slim down to one.

Thanks

Phil