How Can I Identify Performance Bottlenecks in My App Development Workflow?

App Inventor for iOS
1

Hi everyone,

I’m currently working on some app projects using MIT App Inventor, and performance optimization is becoming increasingly important as my apps grow more complex.

While I focus on optimizing my app’s logic and user interface, I started wondering how much of the slowdown during testing might actually be due to hardware limitations on my development machine.

To better understand this, I’ve been using a tool called Bottleneck Calculator (my bottle neck calculator) that analyzes the balance between CPU, GPU, and RAM on my system. It helps me identify if my hardware might be causing bottlenecks that affect app testing speed and performance.

Has anyone here tried similar approaches to diagnose system bottlenecks while developing apps? Any tips on optimizing both the app and development environment for smoother testing would be really appreciated.

Thanks!

2

what kind of app you are making? and how complex?

5

(Canned Reply)
When you have too many blocks spread out over too large a surface area,
the Blocks Editor hits a complexity limit when it tries to generate a blocks.png file for the screen.

There are two main approaches to deal with this:

  • Start a Google Doc with a Table of Contents explaining your app, with sections for Design, Data, Code, including Downloaded Png images of all Events, Procedures, Globals, and with html cross-links for easy navigation. Such a doc becomes easier to read than a complete blocks image, because you have FIND, Next, PREV, back functionality, and you can add paragraphs of commentary around your code. This is my preferred life saver when doing a very large complex app. If you go this route, try to arrange your blocks geographically in a column matching the order of your Table of Contents, then do periodic Clean Up Blocks to pull them inline. This sometimes lowers the load on the Blocks Editor.
  • Reduce your block count:
    • Use parametrized procedures for common code
    • Use Media text files instead of big clumps of text blocks
    • Use generic blocks instead of repeating component event blocks
    • Encode repeating decision patterns into lookup tables loaded from Media csv text files (does your blocks image look like a box of combs?)
    • You don't need a component for every data instance. Reuse those components.
    • If you can't fit data into a ListView or List Picker, show a small subset of the data in an Arrangement and slide it across the larger list of data.

..