Ever since Thunkable X was updated to include app, stored, and cloud variable types, the speed on Android while using these variables has plummeted. There are seconds of lag when filling up a bunch of labels with text values from variables. But it doesn’t slow down as much when using local variables that are auto generated. See example test project…
Sorry to hear that you’ve been dealing with this for so long now. Can you let us know whether this is only affecting the live testing app or of the behaviour is the same for apps that are installed directly on your device?
live and downloaded/installed android apps. tested on many different android devices. all slow. iphones are unaffected when using variables to fill text labels and fill really fast. Android is super slow for some reason as soon as a (app/stored/cloud) variable is involved. for-loop, screen “local” variables don’t affect speed and perform as expected.
I am seeing the same issue and I believe this should be treated as a high-priority one. We now can leverage the clone feature to dynamically add components on screen using a loop, filling each of the components with information from a local DB. However, as the assigning of text values to the components, it renders the clone feature practically unusable especially when you clone more than 10 times and the element you clone is a bit “complex” such as a column which contains rows, buttons and labels.
I have created a benchmark app which demonstrates three (3) bugs/issues:
Cloning elements slows down significantly as clones get generated
Assigning text to elements is very slow on Android (this is the issue described in this thread)
Using a “count” loop to clone elements will not show the cloned elements on screen as they get created unless you add a variable change in the loop. (yup… don’t ask me how I spotted this).
If cloning occurs in a loop, then copies will not be displayed on the screen, because the execution of the loop blocks the execution of the main stream, in which the information on the screen is updated. Use a delay block with a small value to delay iterations and provide the system with time to update the information on the screen.
It’s slow whether the label value is assigned inside a loop or manually one by one. It delays/lags when setting the label value from a variable (on android). I only used a loop and component creates to illustrate it quicker.
Hey @actech, not sure I can agree with what you mention. My test app proves exactly the point I make, unless by “loop” you only mean the “count” loop and not the “While” and “Repeat” loops which in fact do render the cloned elements on screen as they get created. The “Count” loop will also render the clones but only if you update a variable in the loop, even if that has nothing to do with the cloned elements. Check my test app for that.
Here is a modification of @Deluxe 's example with an extra tab at the bottom that takes you to a screen that fills labels with and without variables to see the performance differences…
@Mark has a fix that should speed up the variables, which will be in our next release
The speed of cloning is definitely slower than it should be. I’ll take a closer look into it after the first version of the canvas component is online. Thanks @Deluxe and@IWS for the demos and @actech for the correct observations.
You want to say that on your device the addition of a standby unit does not lead to a screen refresh? It works for me on both iOS and the Android emulator.
I never said that. What I said was that in order to see the clones as they get created I added a variable change block. That’s all. I never said that your solution does not work. That was your interpretation.
On the other hand, I do believe that this is a “Count” loop bug because I am not getting this issue with the “While” and “Repeat” loops which do not require our tricks to show the cloned elements as they get created. Unless of course we don’t consider “While” and “Repeat” as loops.
In any case, I am glad we brought this to the attention of the Thunkable devs who will fix the issues.
Well, let’s clarify such a moment. In the figure below, there is no counter update block in the loop. On my Android emulator, while this cycle is running, the screen also does not refresh. Is there a screen update on your device?
Delays less than 10 ms does not make sense to set. The speed of the core of the system will not allow to obtain less delay.
On my iPhone6 (iOS 12.4) blocks are displayed for about 6 seconds.
If instead of using the app loopCounter global block, you use a function variable, the loop will execute in 4 seconds. This suggests that blocks of global variables are slow.
If only the cloning block is left in the loop, the loop will be executed in 1.6-1.7 seconds.
If you need maximum clone creation speed, you should not update the screen when creating them due to a noticeable drop in speed. Instead, use the Loading Icon component.
I understood. On my Android emulator, when I click on the Repeat, While and Count buttons, everything works the same way - when the loop is running, clones appear on the screen. When I click on Count v2 clones appear only after the completion of the loop.
I conducted a small test of the speed of some blocks and I can say that in the current version of Thunkable X there really are big problems with the speed of some blocks and the display of data on the screen.
The most amazing example is shown below. This is another reason why I try not to use global variables.
