Managing RAM with Livecode

[William Jamieson]

Couldn't find anything on this in the forums so I figured I would ask. (May just not be searching well)

How does one make their app most efficient with their use of RAM?

I know that for especially mobile devices that it is important to conserve RAM as it takes up energy which drains peoples batteries. So the goal is to make the application as "lean" as possible. So I was wondering if someone else knows some ways of reducing excess energy expenditure.

Some thoughts:
If variables are created and destroyed as they move through handlers throughout the scripts, is storing data into global variables going to take up more RAM than local (keeps it longer)
If variables are so readily used, is storing data in a custom property a different way of storing data such as in-app storage?
If I needed to hold data for later, would putting it into a txt file or a binfile be an efficient way to clear the data out of RAM temporarily?
Is there anything that can make a difference to the amount of RAM used?

[FourthWorld]

All of the RAM available to a computing device is consuming power whenever the device is on. Additional power consumption is more significant with processing time and moving things between RAM and persistent storage (disk, SSD, Flash memory, etc).

On low-memory devices like phones, RAM can be worth conserving so it can be available for other processes. But the amount of power used by keeping something in RAM is nothing compared to the cost of moving it back and forth from storage. After all, the RAM chip needs to continually consume power anyway, but moving data from storage means CPU time and storage controller time which would otherwise be idle.

As for globals, there are some who believe globals have no place in any language, yet we see that most languages support them. Use 'em when you need 'em, such as data that needs to be accessed globally across your application. There are sometimes stylistics or maintenance reasons to consider alternatives, but when a global is a good fit for a problem it's hard to beat for efficiency.

One useful caveat with globals is a concern about data integrity, since any handler can alter them at any time. Good to be mindful of that, and while alternatives are rarely as efficient (custom props or accessor handlers, for example) sometimes a little extra CPU time spent on ensuring data integrity is a good investment.

A friend uses the phrase "Going to TOWN" when discussing lean systems: Touch Only What's Needed. Be mindful of disk accesses, redundant operations, and slow algorithms. If an image is used more than once, consider rendering them as icons in buttons; if the contents of a variable can be safely passed by reference it's cheaper to move a 4-byte address than to copy the value (though with v7 forward much of that is automatically done for us now); where code can cleanly and reliably use the local "it" variable it can save one more initialization. Be willing to experiment to find ever-leaner methods. There's always a better way.

And all the while, be willing to be okay with something that just works. There's little point in spending weeks of development time to trim a couple milliseconds. After all, imperfect code that ships is infinitely more useful than perfect code that never ships.

[William Jamieson]

Cool. Thank you for elaborating on your understanding of processing power. It is good to know what things to focus on. From what your saying, I took that it doesn't matter how you store it, what matters more is how accessible is it, and does the data need to move. When storing hundreds of small images in a global variable I was hoping to not have my app drain someones battery. However, using my app would be the first thing to worry about. Thanks Richard for your insight!

-Will

[FourthWorld]

Ah, images. You can put the entire set of Android programming references into a variable smaller than a single JPEG photo. Unless they're very small images it may be fine for performance of your own app, but may slow down others as they need to swap/page.

But even if small, it may be helpful to remember that an image in a variable can't be seen, and must be copied to an object to be useful as an image. And of course, copying takes both time and space.

It may be leaner with both RAM and CPU to store those as image objects in a stack file. If there are a lot of them it may be good to reference them from disk; a modest cost to CPU time but a BIG savings on RAM.

And if you use a given image more than once, it'll be much more efficient to display the image as a button icon rather than a copy.