Resource hungry controls

Is there a list or reference to the overhead each control class uses? I would think that controls like the text field and canvas were controls that one should use sparingly. The canvas could be seen as a programmable drawing pallet and the text field could be seen as a mini word processor. All of this looks like big system resources overhead to me. Have I got it wrong? Are we at the point in computing where run-time memory is so fast an plentiful, that having 50 canvasses on your drawing app has very little impact on the modern computer. I learned in the early days of computing that you only needed one text field to represent the data entry areas of a screen full of prompt areas by simply adjusting the x/y coords and visibility of the one text field. To summarise; Is there a list or opinion on what controls to use and which to avoid due to their resource hungry nature? I don’t know how this thread ended up in the ‘customer service’ channel as I added it to the ‘General’ channel

Yes :wink:

Chris, you may want to update your thinking to the new scale of things. Back in the days with 512K RAM and tight disk space, we considered text editors memory hogs. And graphic applications godzillesque monsters.

Today, current machines come with 4 G RAM and commonly 1 TB hard drives, 500 GB minimum. And when back in the days 300 Mhz was outrageously fast, current machines have four cores at over 2 GHz. These are entirely different figures.

The best way you can see which control consumes what is by looking into task monitor. Create an app with nothing on one hand, and another with a TextArea full of text. Actually, the StyledText example probably will do fine. Launch both of them and compare. You will be amazed by the little percentage of resources they need. As some may point out, you are thinking way premature optimization here. Just create an app that works without worrying about resources, and only when it is complete, will it be time to optimize. If ever needed…

512K of RAM, wow, who can afford that type of super computer!!. Seriously though, you may have a point regarding my stone age approach. Working with micro controllers hasn’t helped develop an up to date understanding of what the modern PC and OS are really capable of given that a micro controller usually has 32-64k of RAM with the boot loader taking up a good percentage of that.

I remember an app switching utility I had for Apple IIe that was dividing the 64 K ram into two 32 K pages. That was from Beagle Brothers. We are talking Roman Empire era.

Around the mid 1980s a publisher requested I develop an in-memory, popup up utility à la Sidekick to generate graphs. Pop-up programs were largely considered alchemist master thing at the time. I found a way to put a QuickBasic program in memory that way. But it was taking 64 K out of the common 128 K machines of that time had. It never sold as they had hoped.

We have come a long way :wink: