Execution of a "long" script

[Richard Gaskin]

JB wrote:

 > Can you trust this large script will not crash or should you inform
 > the user the chances of a crash will increase if they use other
 > memory intensive applications.  Is there a way to prevent it?

Any time LiveCode crashes it's a bug that should be reported.  Even with 
low-memory conditions, the app should dip into swap rather than crash. 
This may not always be practical depending on the nature of the task, 
but it's an ideal worth pursuing.  The only errors that should ever 
occur in LC are ones related to our own scripting mistakes.

Apps reflect a wide range of behaviors in low-memory conditions, and 
most apps contain in them somewhere some sort of bug that will cause 
them to crash.  Undesirable, but it happens.

When the issue is exposed by low-memory conditions, the issue is 
compounded by the likelihood that there isn't even enough memory to 
invoke the normal error handling, so that rather than simply stopping 
execution with a warning the app may simply crash instead.

All that said, thanks to the community's rigorous testing and the engine 
team's ardent pursuit of good memory management, many of us have apps 
that have run for many hours or even days without a hiccup (I have one 
here where normal uptime is measured in weeks, usually only interrupted 
because I rebooted the machine for some other reason unrelated to my app).

LiveCode isn't completely bug-free (if it were it might be the first in 
computing history), but AFAIK at this time there are no known memory 
leaks.  The engine team tends to jump on those quickly, so when 
discovered they usually don't live very long.

I would encourage you to pursue any sort of task with LC you like, and 
if you encounter issues to report them.

For very long tasks it can be helpful to introduce means by which the 
apps surrenders time to the OS to attend to other things, either by 
breaking the task up into chunks and calling those chunks with "send", 
or by using "wait 0 with messages".  This will help ensure the OS can do 
its job with memory shuffling and other things it needs to do to keep up 
with LiveCode.

And FWIW, on some Mac systems I've seen surprisingly poor throttling at 
the OS level, in which some processes have been allowed to run to the 
point that it overheats the CPU.  Most modern motherboards contain 
temperature monitors that shut the machine down before the heat can 
damage components (even the super-cheap mobo I got from Biostar recently 
for $59 has this), but one of my Mac laptops went through three 
motherboards as a result of overheating.  A single date point like one 
Mac isn't enough to suggest that this is endemic or epidemic to Macs, 
and if it were we'd have read about it in the Apple support forums more 
frequently.  Just something to keep in mind which may potentially affect 
any system, providing good motivation for periodically freeing up clock 
cycles to let the system at least do the things it needs to do for 
monitoring.

After all, if a task is going to take several hours, what's a little 
extra time introduced by sharing the CPU?

There are other things to consider as well:  sometimes a long task is 
just a long task, but often there are means to reduce the processing 
time through seemingly-small refinements in the code.  Using "repeat for 
each..." instead of "repeat with i = 1 to ..." is a common example, but 
there may be others which also provide an order-of-magnitude speed boost.

And for really long tasks there are ways of spreading the work across 
multiple computers on your LAN with a sort of MapReduce.  A bit of work 
to set up and certainly carries a lot of overhead, but for a task that 
takes the better part of a day it may be worth the effort to explore.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com