I already wrote about this. I use Yandex browser and noticed that serious inhibition occurs immediately after adding at least one initialization block to the screen. After removing this block (no initialization block remains on the screen), the work is immediately accelerated and now I can work with 500-600 blocks without any problems.
1 Like
Iâm confused what you mean by initialization block. Can you show me what kind of block you mean or explain please. Thanks
1 Like
This block causes a slowdown. Therefore, I use it only when absolutely necessary and at the very end of debugging a project.
2 Likes
Ahhhh ok makes sense. Sorry I wasnât catching that it said initialize LOL. Maybe I should use the local DB instead of a variable then. I wonder how much smoother it would be.
Try it. I, for example, use the Local Storage component. It is interesting to know what you say about the speed of work with local DB. Please note that I do not use Chrome or Firefox. They work for me significantly worse Yandex-browser.
1 Like
Thats what I ment. Good lord LOL Ive been working on my app for 14 hrs/ day LOL.
1 Like
Do you get a slow down using the functions blocks? I am thinking of sending data to them but they use a âvariableâ block now also but not from the initialize blocks.
1 Like
Yes, I use variable blocks from functions. Note that there is some difference in their use relative to global variable blocks. I can not say, but I had a situation where the replacement of a functional variable with a global variable caused the algorithm to stop working altogether.
2 Likes
Youâre right, I removed the initialize variable blocks and itâs smooth. Nice catch!!
1 Like
@Ionut_Ilie, Sorry about the terrible lag. Are you talking about slowness in the browser or slowness in updating the Thunkable Live companion app? With that relatively small number of blocks I wouldnât expect that kind of performance, especially not in the browser. What browser are you using and on what kind of computer? How is your general connectivity to x.thunkable.com? How long does your project initially take to load in the browser?
-Mark
1 Like
I made a screen containing 1000 blocks and all the work in the block editor froze! Unfortunately, it is impossible to simplify.
In the course of work, I noticed that braking causes the use of Any Component blocks in a huge âifâ block.
How to fix it? Youâd be surprised, but this whole block can be replaced with just one block, which is shown below.
In this superblock, the component type, component, method, and value are specified using variables.
2 Likes
block moving is very slow. 10 seconds per change. pls adviseâŚ
cannot work
1 Like
I have a screen with a large number of blocks. The blocks execute fine on my device so everything is working great, but the Thunkable block editor on my PC is very laggy. Anytime I move or modify a block, there is a delay before I am able to move or modify the next block.
When checking the javascript console, there are a very large number of errors âunable to find component with id nullâ that are being logged while the site is unresponsive. Is there any way for the Thunkable team to trace the source of this error? Because I believe it would eliminate the very annoying delay I am experiencing.
Thanks!
1 Like
Hi @Kyle_Williams,
To the best of my recollection these are warnings rather than errors. Errors will be in red, whereas warnings ate yellow/orange in colour.
In any event, I donât think these warnings are causing the lag youâre noticing. Just one more thing to help us out here:
How many blocks are on this screen? (You can right click to see how many blocks you have)
You are right, there are errors (in yellow) in Chrome. I should have specified. The only reason Iâm suspicious that they are related to the lag is that if I monitor the console while I modify a block, the page becomes unresponsive the moment the console starts logging these warnings, and becomes responsive again the moment the last warning has logged.
There are 855. Yeah, I know, itâs a lot lol. The code all executes just fine on my device, itâs just a pain to make modifications. I would have significantly less blocks if I could address components programmatically (as far as I know, this is only possible with variables).
I have got the same problem with lagging and i have 4300 blocks in one screen
is there any solution to stop the editor from lagging its a pain to edit the blocks on the screen due to the lag??
1 Like
I have an app with 6212 blocks (I do mean 6 thousand).
It WILL lag because you are moving around an image that is several times the size of your screen and that has to be loaded each time. I do not think that it can be improved, large apps are simply stressing the system.
Question for you both, since you have wayyyy more blocks than I do. Did the block editor suddenly become laggy, or did it gradually get laggier and laggier as time went by? And as you add more blocks, is it getting more laggy, or is the amount of lag staying about the same?
I ask because my block editor seemed fine until around 500 blocks, and it suddenly developed 3-5 seconds of lag after edits. But as Iâve added more blocks, that amount of lag has seemed to stay the same, rather than increasing along with the block count. Iâm just curious as to what you two have experienced.
For me it gradually started to lag as u said after reaching a certain number of blocks but its been like that since then its not increasing with the number of blocks as of now atleast cant say how it will behave after i add more blocks to it!!
1 Like
I do not remember how progressively it happened, and how many blocks it started getting really slow.
But for the record, there are a few techniques I developed to reduce the discomfort. This is on Classic by the way, not on X; but I have no reason to believe it would not work out the same.
1- I scale the overall display at 50% (âCTRL -â a few times) so that I have more of the layout on the display at the same time. That helps reduce the need to scroll. Of course things are smaller and harder to read, but 50% works for me.
2- I also try to keep all the blocks tightly fitted (to the point of having to move some around to make room for a block that needs expanding). Again, less scrolling at times, but more at others. You could also collapse the blocks that you do not see a need for editing, again to tighten the display, although, if you are like me, chances are the bit of code you need to review would then tend to be collapsed so you have to expand them all just looking for the bit you are after, and that ends up wasting more time than saving.
3- I noticed that scrolling around the block editor is faster as long as you do not mouse click in the field (and therefore select a block or call whatever function would be trying to identify which block was selected). To scroll around over large area, do not use the mouse click and drag technique, rely on the scroll bars on the side and bottom, or the scroll wheel of the mouse instead.
4- 3-5 seconds lag? I wish I had it that fast⌠I will get worse if you have more blocks. At some point, you may even need to reload the project and restart because of time out and session expiry. Good thing thunkable has auto-save, you will usually not lose anything except time.
In order to cope, I made a point of naming the blocks (a prefix to the function name, and to buttons and other objects) that will, if I call the arrange or sort block features, organize them in a predictable manner (alphabetically). The idea is to name the functions and components events such that they will be functionally regrouped; again this reduce the need to scroll. It also helps figuring out in which direction to scroll to get to a function that is out of the current view.
Another thing to consider when you get to several thousand blocks (which may or may not be pertinent in the present case) is what I would call ânumerical instabilitiesâ.
The reason it may no longer apply is that I started developing several years ago on MIT App Inventor, and Thunkable is more or less an offshoot thereof. App Inventor may have fixed that issue, or not; and Thunkable may also have that issue, or not, but experiencing it is painful.
My app was positively huge, above 10000 blocks, if I recall properly, and I just could not get it to run.
Then I started trimming, finding areas where processing was similar enough that they could be turned over to a function made generic enough, using arguments that allowed them to work properly in the different instances, and porting some activities to different screens. Then it was running.
But as I developed further, found that between 5000 and 6000 blocks in a screen, the program would start misbehaving: I had a result that was evidently bad, and when I identified the place where the alleged error was coming from by adding some debug statements, the error would go away⌠but land somewhere else. This is similar to what we call a âmemory leakâ, so figured that perhaps there was a limit to the number of statements the environment could gracefully juggle, and decided it was best to avoid getting significantly above the 5000-6000 blocks for each screen. So, my app with 6212 blocks in one screen is actually in the yellow alert zone already (for the record, the app on MIT eventually totaled 17033 blocks, over 6 screens, all of them below 5000 however).
Reducing the number of blocks actually ended taking far more time than developing the code. And how to reduce involved many techniques:
1- making use of âAny componentâ to prepare list of objects that should be affected in a similar way (that is how I resize fonts for all objects). Unfortunately, this does not appear to exist in X; although I wonder if the âobjectâ components could be used for this purpose.
2- merciless code reuseâthat means pushing everything that is computed more than once in a similar manner into a callable function
3- porting processing to a different screen â I even have screens that will not even show up; screen A would call screen B with arguments, and screen B will process and close itself returning result to screen A; if the processing is fast enough, that would not even register as a blip on the device; but you could save enough blocks in already crowded screen A.
4- porting processing outside of the code itself, using web viewer calling a HTML file that processes data using JavaScript; for the record, this will work even if the web viewer is hidden. The problem here is that the app needs to exchange data with the web viewer using the webview_string, and that specific capability is not in X thunkable. Note that there is also an appreciable performance gain with an HTML/JavaScript processing; my app needs to sort ~400 entries from a list, and even using the best algorithm (heap sort) encoded in thunkable blocks required between 3.1 and 3.5 seconds, way too long a response time when someone clicks a button. But having the app take all the data from the list and put them in a (very long) text string, send that as webview_string to a web viewer that loads a HTML/JavaScript with the heap sort coded there, and receive the sorted list through the same webview_string, which is then parsed and used to populate the list to be displayed for the user to pick, was running about 700 times faster.
So there is far more possible issues in there than just scrolling around if you app is destined to get really large.
1 Like