Hi and hello,
I use extensively handler, repeats and properties, with
dialogs, ect. but nevertheless,seems that my last applescripts consumes alot of ram. (They are also a bit long)
I’m in trouble with applescript. I saw some scripts using alot of variables with only a few commands. Incredible.
It’s impossible to comment on that without seeing your scripts.
One thing to consider is that the values of properties, globals, and run-handler variables persist and are part of the script. If you use a lot of them, and they have bulky values such as long texts or lists, that could cause a good deal of bloat. Local variables, on the other hand, are only temporary and cease to exist when the handler in which they’re used exits. The memory used by their values is then handed back to the system unless those values are passed on to variables that are still current. I use local variables wherever possible. One way to do this without having to make a lot of local declarations is to put as much of the code as possible into ordinary handlers. Instead of this .
-- Pseudocode:
set this to that
set that to somethingElse
do lots of other stuff involving other variables
. do this:
-- Pseudocode:
on main() -- or whatver you want to call your main handler.
-- All variables in a handler are local unless declared otherwise.
set this to that
set that to somethingElse
do lots of other stuff involving other variables
end main
main()
That depends on what’s in the handlers ” ie. how many parameters you’re passing to the next handler and how much has to be remembered to get back to the calling handler with the values of its local variables and of the CPU registers restored. All this information is stored in the script’s program stack (or whatever Apple calls it here). Here a few simple tests to test how deep handlers can be nested:
-- No parameters or local variables.
global n
on recurse()
set n to n + 1
recurse()
end recurse
set n to 0
try -- Recurse until stack error.
recurse()
end try
n --> 734 on my machine.
-- Ten parameters per call, no locals within the handlers.
global n
on recurse(a, b, c, d, e, f, g, h, i, j)
set n to n + 1
recurse(a, b, c, d, e, f, g, h, i, j)
end recurse
set n to 0
set {a, b, c, d, e, f, g, h, i, j} to {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
try -- Recurse until stack error.
recurse(a, b, c, d, e, f, g, h, i, j)
end try
n --> 260 on my machine.
-- Ten parameters per call, one local variable per handler.
global n
on recurse(a, b, c, d, e, f, g, h, i, j)
set p to 37
set n to n + 1
recurse(a, b, c, d, e, f, g, h, i, j)
end recurse
set n to 0
set {a, b, c, d, e, f, g, h, i, j} to {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
try -- Recurse until stack error.
recurse(a, b, c, d, e, f, g, h, i, j)
end try
n --> 252 on my machine.
But scripts very rarely need to go that deep!
Hello.
It is nice with such an empirical treatise of the subject.
I tested the first recursing example in Script Debugger and Script Editor and Smile.
Both Script Debugger and Script Editor returned 734 like your example.
Smile on the other hand returned an astonishing 3050387! 
Smile returned 1082395 with the second example and 1048570 with the third example! 
If this is not due to some error then there is no doubt were one would do heavy computations with AppleScript.
Best Regards
McUsr
I would not be surprised to learn that Smile and Script Debugger define a larger stack area than the Apple’s tool.
Yvan KOENIG (VALLAURIS, France) dimanche 4 juillet 2010 12:17:44
Hello.
Script Debugger actually didn’t in Nigel’s first example, that’s why I didn’t bother to test it further.
But Smile. 4155 times larger stack space in the first example.
Best Regards
McUsr