What is the optimal trade off between refactoring and increasing the call stack?

Question

I'm looking at refactoring a lot of large (1000+ lines) methods into nice chunks that can then be unit tested as appropriate.

This started me thinking about the call stack, as many of my rafactored blocks have other refactored blocks within them, and my large methods may well have been called by other large methods.

I'd like to open this for discussion to see if refactoring can lead to call stack issues. I doubt it will in most cases, but wondered about refactored recursive methods and whether it would be possible to cause a stack overflow without creating an infinite loop?

Answer 1

Excluding recursion, I wouldn't worry about call stack issues until they appear (which they likely won't).

Regarding recursion: it must be carefully implemented and carefully tested no matter how it's done so this would be no different.

Answer 2

I guess it's technically possible. But not something that I would worry about unless it actually happens when I test my code.

Answer 3

When I was a kid, and computers had 64K of RAM, the call stack size mattered.

Nowadays, it's hardly worth discussing. Memory is huge, stack frames are small, a few extra function calls are hardly measurable.

As an example, Python has an artificially small call stack so it detects infinite recursion promptly. The default size is 1000 frames, but this is adjustable with a simple API call.

The only way to run afoul of the stack in Python is to tackle Project Euler problems without thinking. Even then, you typically run out of time before you run out of stack. (100 trillion loops would take far longer than a human lifespan.)

Answer 4

I think it's highly unlikely for you to get a stackoverflow without recursion when refactoring. The only way that I can see that this would happen is if you are allocating and/or passing a lot of data between methods on the stack itself.