Should running a program at the smallest call stack depth be pursued?

[Tony]

Is there any value to pursuing program designs that mimimize
the mainline call stack? For example, within main() I could
code up something like:

while(GetMsg(m))
DispatchMsg(m);

instead of doing Program.Run() from main() or even worse
calling Run() from the Program constructor.

Call Stack example 1:
main()
GetMsg()/DispatchMsg()

Call Stack example 2:

main()
Program:rogram()
Program::Run()
GetMsg()/DispatchMsg()

Tony

 

[red floyd]

Is there any value to pursuing program designs that mimimize
the mainline call stack? For example, within main() I could
code up something like:

while(GetMsg(m))
DispatchMsg(m);

instead of doing Program.Run() from main() or even worse
calling Run() from the Program constructor.

Call Stack example 1:
main()
GetMsg()/DispatchMsg()

Call Stack example 2:

main()
Program:rogram()
Program::Run()
GetMsg()/DispatchMsg()

Tony

Given that your platform appears to be Win32, no. For certain embedded
systems with fixed/minimal stack, the answer may be yes.

It's platform and application dependent, and YMMV.

 

[Gavin Deane]

Is there any value to pursuing program designs that mimimize
the mainline call stack?

That's a general question. As with any optimisation question, the
general answer is "no need". That should be your starting point. There
are two sets of circumstances where you will change from "no" to "yes".

1. You have proven that the depth of your call-stack makes it
impossible for your program to meet its requirements. [*]
2. You have sufficient knowledge and experience of your compiler and
target platform that you know in advance that the depth of call-stack
you would like to write will make it impossible for your program to
meet its requirements.

If either of the above applies, and only you know that, then make the
optimisation.

[*] In this case the requirements will presumably be in terms of stack
size.

Gavin Deane

 

[Tony]

That's a general question. As with any optimisation question, the
general answer is "no need".

I wasn't necessarily asking from an optimization standpoint. My concern
would be more from the robustness standpoint: if there's a larger surface
area for potential corruption, then maybe it's wise to minimize that.

Tony

 

[Evan]

I wasn't necessarily asking from an optimization standpoint. My concern
would be more from the robustness standpoint: if there's a larger surface
area for potential corruption, then maybe it's wise to minimize that.

Tony

Unless you have a specific threat in mind that you have very good
reason to think that trying to minimize stack height will help prevent
[note: I can't think of any], my feeling is that you're more likely to
introduce errors trying to minimize stack height than you are just
leaving it.

Evan

 

[Noah Roberts]

I wasn't necessarily asking from an optimization standpoint. My concern
would be more from the robustness standpoint: if there's a larger surface
area for potential corruption, then maybe it's wise to minimize that.

Well, no. Recursive functions /can/ be difficult to debug or validate.
They /can/ also be slower than their loopy counterparts. It is rare
that this is really important though and often times an algorithm is
just plain simpler in a recursive form.

Now, as to the general question. How would you alleviate the "problem"
of stack "depth" should you see such a problem? Well, the obvious
answer would be to pull all the functions you are calling up into their
caller so that instead of having a bunch of small, simple, easy to
manage functions you have one great big one. That's bad.

No, there is no need to pursue designs that minimize call depth...in
fact I would say they should be avoided in almost all, if not all,
situations.

 

[Tony]

Well, no. Recursive functions /can/ be difficult to debug or validate.
They /can/ also be slower than their loopy counterparts. It is rare
that this is really important though and often times an algorithm is
just plain simpler in a recursive form.

Now, as to the general question. How would you alleviate the "problem"
of stack "depth" should you see such a problem? Well, the obvious
answer would be to pull all the functions you are calling up into their
caller so that instead of having a bunch of small, simple, easy to
manage functions you have one great big one. That's bad.

I was only really concerned with the main() branch, pretty much like
my examples, rather than in general. I'm trying to come up with an entry
point mechanism other than main().

No, there is no need to pursue designs that minimize call depth...in
fact I would say they should be avoided in almost all, if not all,
situations.

Well that's some good news for someone considering dumping main()
then.

Tony