I'm reading through the Source Making site, specifically the Refactoring section. On the page describing the Long Method problem, the following statement is made:
Older languages carried an overhead in subroutine calls, which deterred people from small methods. Modern OO languages have pretty much eliminated that overhead for in-process calls.
I'm just wondering how modern OO has done that and how does that compare to the "old" way?
I think you are wise to kind of trip over that statement. It makes no sense.
Really, I don't believe that statement at all. What has happened is that the CPU's have become remarkably fast, literally a thousand times faster than they were when those old languages were designed.
Programs have also become more sophisticated. At this point, we don't care about the (now) tiny amount of overhead involved in "branch and link" or whatever the function call mechanism is. We have millions of pixels to paint, or a database to access, or a network to feed. These operations are expensive, in a way. A method call is in the noise.
There is a lot less overhead in making a method call in C than in any modern language. After all, the modern language has a CLR or JVM or Ruby interpreter that is written in C in the first place.
But it doesn't matter. The CPU is fast enough to kick the program into next week. What matters is keeping the layers and layers of (largely now OO) software working correctly, and the modern languages help us do that, as well as make it easier to write in the first place.
Really, they are slower, not faster, because that's how we want it now. 3x the overhead, 1000x the CPU speed, we still win by 300, and have a better language.