On large projects, the operation of the screen and blocks editor is increasingly slowed down
What exactly are the reasons for the slowdown in performance when working with large projects?
Is the number of archived projects important or does it not influence?
In addition to the number of blocks, what are the parameters that influence performance during the development of a project?
1 Like
No. I have lots of projects. (I have exported .aia files for all of them too, of course.)
Block count is the major limitation in the browser. You can reduce it by
- Using Media .txt files instead of text blocks for builtin data
- reducing redundancy using procedures and generic blocks (does your Downloaded Blocks Image look like a box of combs?)
- Collapsing blocks when not being editted and doing periodic Clean Up Blocks to reduce active surface area reduces the need for checking imminent dock events
Also, don't waste your bandwidth. No videos while coding.
Keeping the Companion up to date with your latest app updates is a performance drain. Connect when you're ready to test, not before.
In my case, the space occupied in the screen by 5500 blocks seems to be the limit.
I'm not longer capable to Download Blocks as Image (a wonderful method of documenting the work done, and searching for bugs offline, when two apps interact with each other).
Some time ago, I tried to solve it by moving some blocks to a different screen, and it worked for some time. But then the project grew, and I'm stuck again.
The problem doesn't seem to be the absolute number of blocks, but the space they occupy in the screen.
I follow a strict rule on the width, and the space occupied grows only in height.
I got some improvement by rearranging the blocks in a "Tetris" like work.
Clean Up doesn't seem to work, because it makes the occupied space even longer.
Does somebody have a piece of advice in this subject?
Will it help getting a more powerful computer, or a faster Internet link?
By the way, when I moved from Google Chrome to Mozilla FireFox, I was able to add some hundred more blocks.
There’s a known performance regression with Chrome and Blockly, the library we use for the blocks editor, so at the moment for larger projects Firefox tends to be more usable.
The primary limitation with the number of blocks is the resources your machine has available (CPU, RAM, and graphics processing). The more of these you have, the more you can put into a workspace before it starts to slow down. One trick you can do is collapse the top level blocks because we do have an optimization to not render as much when they are collapsed.
I gave a talk at the Blockly User Summit 2019 that discusses Blockly performance in App Inventor that may be of interest to you:
1 Like
You can Download Blocks as Image individually, and rename the downloads appropriately (globalTopScoreList.png, sortScores.png, whenScreen1Initialize.png , etc.) and save them on github or Dropbox. This is also handy for use with Blocks Editor drag and drop. When i want to find a procedure in my project collection, I use my Dropbox search against my appinventor master folder.
Thanks a lot Evan, for your early answer and your advice.
I’m already used to see the “Loading…” message for minutes on Firefox (it’s not such a big problem for a patient retired person like me). I assume it’s the price for using a wonderful tool with such a big number of blocks.
To speed up, I will follow your suggestion of collapsing the top level blocks with the highest number of nested blocks on them.
My biggest concern is, it seems to be a physical limit on how much workspace (or how many blocks with lots of comments) is possible to put in a .png file, when trying to Download Blocks as Image.
Do you think that a better computer can increase this limit?
Thanks ABG, for your advice.
I was able to Download Screen1 Blocks as Image, and the blocks.png file is 8MB.
Then I Sorted Blocks by Category, and no longer could Download blocks as Image.
Following your suggestion, I Collapsed a dozen blocks (the ones with highest number of nested blocks inside). Then I could download blocks as image again. The file size went down to 5.8MB.
Then I downloaded those 12 collapsed blocks, renaming their files one by one.
It works, but it would be a lot of work to be done in a daily routine!
If there is any one on this board who needs to do it, it's you.
When your project gets too big to download or build, those downloaded .PNG files may be your only reusable code available to drag into a new Project on the code.appinventor.mit.edu server.
Sample projects on github:
github
Happy to announce that I found the way to save my project to PNG file again (despite being quite a big one).
I had to rearrange all the 5500 blocks in screen1.
The problem was they were set in the workspace in a very tall and thin rectangular shape.
Chrome gave me the hint, drawing to png only the upper part of the workspace, with a blank below.
So I moved the blocks to a new shape (also rectangular, but more square looking) and it worked, generating a 9.3MB PNG file.
I didn’t even need to collapse any block!
Maybe it helped as well to move the laptop closer to the WIFI router, or erasing the browser’s caché.
Hi @Martin_Herraiz,
Thanks for the update. We might be able to use that information to improve the PNG rendering mechanism.
Hi, my application has a lot of blocks and the block editor runs very slowly (there is a pretty big improvement when using firefox, but it's still very slow). Is there an update on this issue? https://drive.google.com/file/d/1JmZ93iQOZ5LWj8kjU9AfwVEND39bwT0v/view?usp=sharing
I think that if it is possible to create several workspaces for each screen then it can help solve the problem - because it will not be necessary to load all the blocks on the screen with each move but only the ones in the workspace (and the block editor can be much more convenient and orderly)
We don't have any concrete plans to work on the blocks editor performance at this time, but if you want to send me the project you're having issues with I can run some tests on it to help us better understand where the bottlenecks might lie.