Stack Overflow

I have a question that will probably make the senior developers' hair stand on end:
My (very large) data field for Edge 1050 occupies about 60% of the available memory (peak barely higher).

If I now declare a few more variables or add an If-Then-Else condition, I get a “stack overflow”.
Is there a recipe to avoid this as much as possible?

I have no nested function calls, where one calls the other…

(I'm just an autodidact - learning by doing)

FlowState 15 days ago

mcinner1 said:
I have no nested function calls,

This isn't the only way to overflow your stack.

The reason it's the typical way to overflow your stack is that each "active" function call occupies space on the stack, so the more functions that call each other without returning, the likelier it is you'll run out of room.

But you could also overflow your stack by simply having one really big active function. (Big in terms of the amount of stack space it occupies)

mcinner1 said:
If I now declare a few more variables

Yes, this is another way to overflow your stack: having lots of local variables. You should be able to get around this by combining some of your local variables into a single class (or using a container object like an Array or Dictionary.)

(All objects other than certain built-in types [*] are allocated on the heap, which means that if a local variable points to such an object, it only occupies a very small amount of memory on the stack which points to the actual object on the heap.)

[*] these types are "primitive" [**] and small: Boolean, Number, Float, Null

[**] In one sense, Monkey C doesn't have primitive types (because all types are objects), and the doc mentions that, but then it goes on to describe certain types as "primitive" anyway. Maybe a better word would be "immutable" - the immutable types are the ones mentioned above along with Double, Long, and String. Although those types are also immutable (or "primitive"), they are allocated on the heap because they're larger than 4 bytes.

Local variables have to be on the stack because the program has to remember them if you call another function during the execution of the current function. The same goes for arguments.

The stack is basically a place for the program to temporarily store the state of every active function.

mcinner1 said:
or add an If-Then-Else condition

Does this condition involve the creation of a new local variable?

mcinner1 said:
Is there a recipe to avoid this as much as possible?

Minimize the number of local variables in a given function and/or try to simplify huge functions by refactoring / splitting them up into smaller functions. The amount of code should not be a problem though; it's really the number of local variables that would be an issue.

mcinner1 15 days ago in reply to FlowState

Thank you FlowState !

Since compute() and onUpdate(dc) are functions, too - I have too much code in both?

I have much work to do each second in compute() - where should I place the code to be calculated each second?
The same for onUpdate(dc) - all the work has to be shown.

I assume I‘m on a wrong coding way in general, because most of my code is in this two main functions…

FlowState said:
Does this condition involve the creation of a new local variable?

In general - no. Most If Then Else are like this:

If settingXY == true
…calculate this / draw this
Else
…calculate that / draw that

flocsy🤠 15 days ago in reply to mcinner1

I don't think it's uncommon to have most of your code in compute and onUpdate or in functions called from there. If you move them into separate functions that alone will just make it worse as explained above, so the other thing you can do is not very nice, but can help: reuse local variables. Instead of?

var halfWidth = width / 2;
...
// use halfWidth until here
var label = mPrefix + " " + heartRate;
// use label

do:

var tmp1 /*halfWidth*/ = width / 2;
...
// use tmp1 /*halfWidth*/ until here
var tmp1 /*label*/ = mPrefix + " " + heartRate;
// use tmp1 /*label*/

One thing that helped me in a few similar cases in Prettier Monkey C. It's an optimzier (amongst other things), that does the above (re-writes the code to re-use local variables that aren't used any more) and much more.

mcinner1 14 days ago in reply to flocsy🤠

flocsy🤠

Thank you for your suggestion! I have understood and will try…