My Data Viewer List/Grid is extremely slow

[skulamester]

Hi there,

I want to make a calendar app, so I need to display the days in a specific month. I would like to display the days in a Data Viewer Grid, so the user can select the appropriate one.

However, Thunkable updates the values in a Table Data Source extremely slow.

Method 1 I tried: (took 23 seconds to load by creating new rows)

I have also tried the DVL hack from @jared, but it got even slower.

Fun Share: DVL Hack

I wanted to share a DVL hack shared by a user via Intercom. I have assembled a simple example here tldr; You can bind a DVL to a blank table with a lotta rows. Set the empty string text to “”. Then loop through the list of table ID’s and assign DVL components properties without ever dumping data into the table! AMA! Can’t wait to see what you all can thunk up with this special sauce! [Screen Shot 2022-01-04 at 4.01.56 PM]

Method 2: (This way, it took 24 seconds to load. )

The days in my calendar are loading extremely slow:
(Here you can see that the app creates the rows one by one, but I need 31 of them to create a whole month, so it takes a lot of time.)

I read in the community, that other thunkers have the same issue as well:

DataViewerList speed testing

Hello Thunkers ! Sometimes an application needs to dynamically build, populate and display a local table on the screen. And I noticed that doing so, DVL become slow in showing results. So I made a simple app to exemplify that, building a table with only 30 rows/9 columns with no other beautify than changing every row color. And still for that it requires more than 10 seconds to display it (on a real fast phone, a Qualcomm Snapdragon 888 Octa-core RealMe GT edition). This is the link to app, …

Does anyone have a workaround for this or is Thunkable planning to make tables faster?

Thank you!

[tatiang]

In Method 1, you are:

1. Calling an API and waiting for the response
2. Looping through a list using a stored variable
3. Creating rows in a data source

Each of those is a slow-ish process. But there are some things you can do/consider:

1. How long does the API response take? I once used an API that took 12-20 seconds to respond. I thought for sure Thunkable was just really slow to update data from cloud sources until I realized that the 16 seconds it was taking included about 14 seconds waiting for the API. Each API (and specific call) will be different in this regard.

2. Read/write using stored variables is SLOW. Any time you need to access or save a value with a stored variable, do this instead: set an app variable to the stored variable’s value. Use/update the app variable as needed. At the end (e.g. outside of a loop), set the stored variable to the app variable’s value.

3. Creating rows can take a while especially if you’re creating dozens or hundreds of rows (how many are you creating on average?). Consider using a faster method such as Firebase (really fast!) or Google Apps scripting.

For Method 2, I would make your code more efficient by replacing all of the repetitive list blocks with variables. So for example, you have in list app variable ready get # i six times. Instead, when the loop starts, set a variable to that value (in list app variable ready get # i) and then use the variable in those six places in your code. I can’t say how much that will speed things up – maybe just a little – but it should be faster to get a value from a variable over and over than to get a list item over and over. And again, you’re using three stored variables. Fortunately, they aren’t in a loop. But each time you call the API, it has to make three retrievals of stored values. So instead, when the screen opens (for example), set app variables to those stored variable values and use the app variables inside the function instead.

Another option, which you may have already thought of, is to clone blocks instead of using a DVL. That tends to be faster and gives you a lot of control over the look of the “DVL.”

[jared]

check this out!
https://x.thunkable.com/projectPage/6358829b13bd2c31d1f0fbc6

My calendar project is fast af using a layout component and a JavaScript library to produce the dates.

[skulamester]

Thank you for the answers and sorry for my late response.

I created a smaller project to present my problem, because it is not related to the API, stored variable or the number of the rows like @tatiang suggested.

I have 4 examples on how the Data Viewer List/Grid gets slower and slower. I hope that it can help the team to debug the issues in Thunkable and fix this.

Project link: Thunkable

Example 1:
I just create a table without any Data Viewer on the screen. It took: 0.16 seconds for me. I think that should be the optimal.

Example 2:
Creating the same table, but in this case I have a Data Viewer Grid on my screen without any Data Bidings. It took 1.26 seconds for me. I mean I could live with that, but it even get worse in the next example and it is a more than 7 times slower than in example 1.

Example 3:
In example 3, I had the same table, the same DVG, but now I had Data Bidings. It took 2.96 seconds to load, which is more than 18 times slower than example 1.

Example 4:
In this example I changed the code a little bit, I added a simple if block inside the loop, and I got 4.82, which is extremely slow and is 30 TIMES SLOWER than in example 1.

I understand, that it should load slower, because displaying the items in the Grid, but this is too slow, waiting 4-5 seconds to display a calendar like I want to is extremely slow.

I don’t want to clone blocks as @jared suggested, because my Data Viewer Layout contains more components and detecting a click event for all of them would be impossible. Or do you have an idea how the click event for a column like this should like?

Thank you again for your time and answers and I hope that @Thunkable_Staff will have a look on this.

[skulamester]

The results in my previous post was from my iOS device. Testing the same app on an Android device results:

Example 1: 0.69 seconds
Example 2: 4.84 seconds
Example 3: 9.37 seconds
Example 4: 14.36 seconds

So in Android the situation is even worse. Live apps and built apps produce the same results. In bigger projects it even gets worse like in the main post:

@skulamester

took 23 seconds to load by creating new rows

[tatiang]

It took 5 seconds on an Android device to just display a DVG?! How many rows does that data source have?

Is it taking that long because as you scroll down, the data isn’t visible until you wait a little and then scroll down again and then wait…?

[martint]

The local table data source speed issue has been comented on several times over the last few years including by myself in March 21, Local Data Source Table very slow
I have very recently revisited the DVL combined with Local table and discovered the speed isuue is still present.

[tatiang]

So the faster alternatives are to use Firebase or the Airtable API. Unfortunately, both of those require you to use clones instead of the built-in data sources. I do think this is a problem Thunkable should fix - if they can. We really should be able to rely on the DVL/DVG as is.

[skulamester]

@tatiang

It took 5 seconds on an Android device to just display a DVG?! How many rows does that data source have?

Yes it took 5 seconds. However, I think that it depends on the phone’s performance, because on an Galaxy S8+ (with screen recorder turned on) it took 9+ seconds to display 30 rows (I display 30 rows because I want to make a calendar app):

However, on my iPhone, it is 1.35 seconds, which is still very slow regarding that it is just Example 2 meaning this is an empty Data Viewer with no Data Bidings.

If I am testing Example 3 (meaning I have Data Bidings) it is very slow, 3.17 seconds:

On Android, the same test without a screen recorder is 9.37 seconds.

I tested Drag and Drop and Snap to Place UI’s too.

@tatiang

Is it taking that long because as you scroll down, the data isn’t visible until you wait a little and then scroll down again and then wait…?

No, it is not depending on the scrolling on my phones, but you could test it on your phone and show me your results, here is the link to the project:

@skulamester

Project link: Thunkable

@martint

The local table data source speed issue

Yes, It could be not because of the DVL, there might be something wrong with Local Table data source.

@tatiang

use Firebase or the Airtable

Unfortunately, that cannot be the case in my situation.

@tatiang

Thunkable should fix

I really believe that it could be fixed, because it is easy to reproduce. I am developing a calendar-like app right now and want it to release in the coming months, but with a such a slow Local Table my app is be unusable.

I hope that @conroy33 ot @Thunkable_Staff could look into this, so I can finish my app, buy a Pro Plan and publish it.

[jared]

That’s whack. I’d use the layouts component. I have already shared how to build a calendar using it.

Fun Share: Calendars in Thunkable

Here’s a calendar that’s made using the Luxon javascript library, the web viewer, and a DVL. There’s several ways to bring a calendar into your app now! check it out! you may need to view this on a mobile device for propper formatting! project page *** updated link ^^^^ ***