On Thursday, April 13, 2017 18:01:13 Jérémie Roquet wrote:
> 2017-04-13 17:21 GMT+02:00 Jérémie Roquet <jroquet@arkanosis.net>:
> > Hence a total of 5856 bytes per recursion, or 5719 kiB for 10000
> > recursions.
> Sorry, I meant 1000 recursions, obviously.
> 
> Here are the numbers when compiling using -O3 instead of -O0 -ggdb —
> probably more useful for optimization:
> 
> execlist: 400 bytes
> execpline: 416 bytes
> execpline2: 224 bytes
> execcmd_exec: 4864 bytes
> execshfunc: 336 bytes
> doshfunc: 704 bytes
> runshfunc: 336 bytes
> execode: 80 bytes
> execlist: 400 bytes
> execpline: 416 bytes
> execpline2: 224 bytes
> execcmd_exec: 4864 bytes
> execif: 80 bytes
> 
> Aggregated:
> 
> execlist: 800 bytes
> execpline: 832 bytes
> execpline2: 448 bytes
> execcmd_exec: 9728 bytes
> execshfunc: 336 bytes
> doshfunc: 704 bytes
> runshfunc: 336 bytes
> execode: 80 bytes
> execif: 80 bytes
> 
> Hence an even higher total of 13344 bytes per recursion, or 13032 kiB
> for 1000 recursions.
> 
> If I'm not mistaken, execcmd_exec seems to account for 73% of the stack
> usage.

Thanks for the analysis!  I tried to apply the attached patch on top of my 
previous patch but the total saving of stack allocation was only up to 10%, 
depending on the compiler flags.  So it is not worth the troubles.  What 
helped significantly to make the default shell call nesting limit reachable 
again was the -fconserve-stack option of GCC.

Kamil