Very interesting. Is your patch available somewhere?

Yep, pushed in 914bcf1 now

So, why this happens? 3 big reasons:

1. Long chains of functions with many args. (Each call thus re-pushes stuff again and again).
2. Good use of automatic variables (non-scalars first of all) and alloca(). The basic idea is that GC of stack stuff is much easier than of heap, but may be worth analyzing that aspect closer.
3. Not good enough use of alloca() - few funcs allocate big enough arrays on stack even if they won't be used.

Of these, 3 looks like low-hanging fruit for experimentation, and I submit this ticket essentially as grounds to tweak 1. Point 2 should be last in row to try, because it will affect performance.

It appears to be similar for the STM port as well:

Stack: 744 bytes
Stack: 1160 bytes
Stack: 1576 bytes

or 416 bytes per level of function call.

My patch was different (sinc stm doesn't have a mem_info, so I added pyb.stack())

diff --git a/stmhal/modpyb.c b/stmhal/modpyb.c
index 7ec2503..de67f62 100644
--- a/stmhal/modpyb.c
+++ b/stmhal/modpyb.c
@@ -147,6 +147,15 @@ STATIC mp_obj_t pyb_info(uint n_args, const mp_obj_t *args) {
 }
 STATIC MP_DEFINE_CONST_FUN_OBJ_VAR_BETWEEN(pyb_info_obj, 0, 1, pyb_info);

+STATIC mp_obj_t pyb_stack(void) {
+    char *stack_top = (char *)&_estack + 1;
+    size_t usage = stack_top - (char *)&stack_top;
+    printf("Stack: %u bytes\n", usage);
+    return mp_const_none;
+}
+STATIC MP_DEFINE_CONST_FUN_OBJ_0(pyb_stack_obj, pyb_stack);
+
+
 //github.com/ \function unique_id()
 //github.com/ Returns a string of 12 bytes (96 bits), which is the unique ID for the MCU.
 STATIC mp_obj_t pyb_unique_id(void) {
@@ -321,6 +330,7 @@ STATIC const mp_map_elem_t pyb_module_globals_table[] = {

     { MP_OBJ_NEW_QSTR(MP_QSTR_bootloader), (mp_obj_t)&pyb_bootloader_obj },
     { MP_OBJ_NEW_QSTR(MP_QSTR_info), (mp_obj_t)&pyb_info_obj },
+    { MP_OBJ_NEW_QSTR(MP_QSTR_stack), (mp_obj_t)&pyb_stack_obj },
     { MP_OBJ_NEW_QSTR(MP_QSTR_unique_id), (mp_obj_t)&pyb_unique_id_obj },
     { MP_OBJ_NEW_QSTR(MP_QSTR_freq), (mp_obj_t)&pyb_freq_obj },
     { MP_OBJ_NEW_QSTR(MP_QSTR_repl_info), (mp_obj_t)&pyb_set_repl_info_obj },
diff --git a/stmhal/qstrdefsport.h b/stmhal/qstrdefsport.h
index d822a54..cb2a38c 100644
--- a/stmhal/qstrdefsport.h
+++ b/stmhal/qstrdefsport.h
@@ -31,6 +31,7 @@ Q(pyb)
 Q(unique_id)
 Q(bootloader)
 Q(info)
+Q(stack)
 Q(sd_test)
 Q(present)
 Q(power)

This really should be micropython.stack() (to return int). mem_info() is dirty practical hack, we should avoid proliferating those (unix just already has it, until it's removed).

I'm working on (initial steps of) point 1.

https://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Static-Stack-Usage-Analysis.html

While trying -fstack-usage and then looking into assembly, I saw completely nonsensical stack usage and allocation. Ah, gotta remember that Intel sells new CPUs by forcing completely ludicrous stack alignments to push more data out of caches and then putting bigger cache sizes to increase something in specs.

Using -mpreferred-stack-boundary=2 (value is power of 2) cut stack size of one function from 80 to 60 bytes (even though default alignment should be 16). Then, one Py function recursion equals 292 bytes (with some changes to cut allocation already applied).

This really should be micropython.stack() (to return int). mem_info() is dirty practical hack, we should avoid proliferating those (unix just already has it, until it's removed).

Good point. I wasn't really sure exactly how/where we should add such a function. It seems quite useful for embedded work.

I like to have a set of functions related to stack use:

1 - Have a function which can write the unused portion of the stack with some well known fixed value
2 - Have a function which scans the stack looking for the first disturbed word. As long as the stack hasn't overflowed this gives a good indication for high-water stack usage, taking into consideration stacked up ISRs and such.

3 - Have a function similar to the one coded which reports on the current stack usage.

Under linux, doing this is a bit tricky, but still doable. The stack grows dynamically, getting new pages added as needed, so you need to probe to find out if pages have been allocated or not. Usually you can query /proc/self/maps and look for a line with [stack] to find the set of pages which are mapped to the stack, and use that as the starting point.

You may also, for debugging purposes, just force the preallocation of a bunch of stack pages.

Perhaps we should create a stack module? Or maybe we should have a mem module that includes the stack and the gc? Or maybe just keep them separate? Once embedded projects get more complicated, I can definitely see the need to walk the heap and get information about all of the allocated objects in the heap, both broad (how many objects are allocated for each class/type) and detailed (get information about each allocated object, especially the larger ones).

Re more sophisticated stack profiling, see also #264.

See c60a261 for some small savings of stack space.

See aabd83e for moderate savings of stack. This patch made the following improvements:

32 bit unix:
    saves 232 ROM bytes
    stack from 384 down to 272 bytes per call (96 words to 68 words)
    -> a saving of 112 bytes (28 words) per call

64 bit unix:
    saves 632 bytes ROM
    stack from 528 to 416 bytes per call (66 down to 52 words)
    -> a saving of 112 bytes stack (14 words)

stmhal:
    saves 48 bytes ROM
    stack from 288 bytes down to 224 bytes (72 words down to 56 words per call)
    -> saves 64 bytes (16 words) per call

So far we have gone from 480 to 272 on x86, and 416 to 224 on ARM Thumb. That's about a 45% decrease.

Sweet.

I saw the blurb about switching over to using the heap if more state is needed. What attributes of a function would cause this to happen? I'd like to understand the impact on interrupt handlers.

What attributes of a function would cause this to happen?

A function that has a lot of local variables, and/or lots of arguments, and/or has a complicated expression, eg a+b*c(d, c+f).

With a few fixes (described above) stack usage is no longer "awful", so the title of this issue is fixed.

If someone considers stack usage to need further improvements, please provide a sensible metric to measure such improvements, and a goal, otherwise this issue will remain forever open.