does anybody else has experience with Screens, which contain more than 400 blocks?
I have such a screen and everytime I make an action, for example create a new block and label it, it takes about 5-6 seconds of loading time. (even if no live companion is connected
This means I can do 10 actions per minute in my project - seems slow and feels slow.
Has anybody else some experience, he or she might want to share?
in one project with which I dealt, there was a screen with 800 blocks (a lot of duplicates). I just could not work with it, because the screen scrolling occurred seconds after 6-7 after I performed this action with the mouse. Therefore, at first I deleted all the repeating blocks and instead made several functions.
HmmâŚthanks for letting us know about the performance problems. The component blocks (events, methods, getters, setters) were coded in a way where the more there are the slower the system gets. Unfortunately itâs going to take a while to fix. Could you or @User81 provide me a link to a slow project? Itâll make it easier to test that my change works when I get to fixing it.
Are you sure, that the automatic compilation is causing the reason?
My non-professional view is:
Thunkable X compiler triggers on every change.
So if I make 10 changes per second, it triggers 10 times per second.
In larger projects (>400 blocks) the compilation takes maybe 500-1000 milliseconds.
That leads to a system, which is nearly always computing!!!
Wouldnât it be a simple solution to turn off automatic compilation for larger projects and let the user trigger the compilation by using a special button or hotkey combination?
You would just need a graphical switch, a boolean variable and a if-then-else block in your compilation trigger section - as easy as this it would be, if your platform would be made with thunkable
thanks for effort in advance,
John
UPDATE: I just tested it. Every compilation needs 13 seconds -> so the automatic compilation trigger is actually useless. -> please let us switch it off and let us trigger compilation manually
@paulmw, John and I talk a little about different issues. John says that automatic compilation slows down work with a multi-block project. I agree with him. I also noticed that the automatic compilation takes place in steps and with poor quality WiFi connection you can see how Live displays every step on the screen. Automatic compilation prevents debugging. I see that something is not working on the screen after editing the blocks and I think that this is a mistake in the blocks, but in fact, Live just did not update to the end point.
Iâm talking about the fact that the slowdown occurs not only because of the compilation, but because of the need to work with a large number of blocks. My experience shows that the drop in speed begins to annoy in the presence of 200-300 blocks. I will try to find that big project on the forum, because it was a project of another user and due to lack of space I deleted it from my account.
thank you @actech for pointing out the relation to WIFI. I can confirm that. That lead me to further testing with the result, that the compiling time is equivalent to the WIFI upload time
@paulmw: This might be interesting for you (if you did not know yet )
I checked two projects with different number of blocks and made 3 times a little dragging on a WHEN-block in the block-section:
my large project with 700 blocks: obeyed compilation time about 13 seconds
You cannot use the total received and total sent values, because I listened to spotify while thunking. But if you look at the sent curve it says for the large project a total of ~2 MB (area under the curve: 200 kB/s * 10 s) is sent via WIFI on each slight change!
My calculations are: if my WIFI / DSL connection is limited to 2 Mbits/s, it takes 10 s for 700 blocks.
â Each Mbit/s speed of your DSL connection lets you compile 35 blocks in one second.
Iâm having a similar problem.
Firefox is pulling 10gb loading up the project and often crashes, but workable if loaded.
Chrome is unworkable although loads easier.
Recently I began to notice a big slowdown of work with the project already at 100-150 blocks on one page. Maybe the speed is affected and the overall size of the project, but I fear that with the increasing number of users work will become slow. I also noticed a serious slow down in work Thunkable Live. Before the pro release about the project was updated in 2-3 seconds, but now I have to stand right under Wi-Fi router and still Thunkable Live starts and is updated very slowly. It may take 10-20 seconds. So many things prefer to watch on PC Android emulator.
Iâm going to bump this because it is becoming so slow that I am not able to work efficiently. Iâve been a long time thunker and love the team, however I am not going to switch to pro for a product that runs as slow as this. My apps start lagging at 150 per screen (im at about 3 screens) or 300 on one screen. Can we please get an update on what is being done for this lag issue? As for my end to troubleshoot, I am using high speed cable internet wired to my PC and use Chrome. I have also tried Firefox with the same results.
Sorry about the lag with large projects. We know about the issue and are thinking about ways to improve the situation. Some of the problem has to do with the underlying third-party package that we are using to define and render the blocks, so itâs a difficult problem. We are also working on some new features that will enable you to significantly reduce the number of blocks that you may need for some common tasks.
There are also a couple of things that you can do to reduce the number of blocks pre screen that you need:
Create functions rather than replicating groups of blocks
Separate functionality into more separate screens when possible
@Mark Thank you for the update. I simply bumped this as the last update was Nov 18. I have tried to reduce blocks and use functions as often as I can however as you know it isnât always possible. One thing I would like to see in Thunkable X is being able to use the âany componentâ tray like in classic so I can cut down on blocks that was a well. It worked well for my game that uses buttons and and requires a lot of blocks. Again, thank you for the update and please try and keep us posted as this is a very problematic issue.
2 weeks I have working on the same screen, because I had 67 blocks, each one with around 5 elements, and for each response of the screen I had to wait 29 seconds. I had worked with a timer.
In the last week I had decided to create the structure at the front-end, and keep the blocks minimal and only to call the front-end structure. But the big structure on front-end create the same delay, even with less blocks. But the waitig time now was around 15 seconds.
In the end I have decided to create 67 screens, each one with the same front-end, no copy and paste, meaning - only for this - around 10 hours without pause.
And it could be ok, I lost almost 2 weeks for a basic screen, but now as I am ready⌠the platform it is not functional rightâŚ
Hey @Mark,
So I noticed some odd things and wondered if maybe this could be causing our lag issue. When I delete blocks with the delete key, after say 5 blocks, my webpage will go blank and I will have to reload the page and the last âdeletedâ block is still there. I also noticed that even after I delete a variable, the blocks are still in the drawer. Could the issue of lag be that when we delete blocks they arent really deleting and the webpage is still trying to process broken information? I am not familiar with how the back-end of thunkable works but I noticed lag on a NEW project at around 250 blocks but I have deleted A LOT of stuff. Just thought iâd point this out. This image below shows all the vairables I have made however most have been deleted from the app.