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?
Modern compilers will actually inline the method for you if it is short (and not virtual), which gives some performance gain.
Apart from that, I don't think that method calls in particular have become so much faster. But on the other hand the computers have. In all cases (but possibly the most extreme ones), it is a better investment to focus on readability, rather than making long methods for performance reasons.
Unless you're writing something like a hardware device driver which has to be incredibly fast, the overhead from setting up a stack frame and making a function call is generally something that's trivial compared to the cost of the alternative. The more twenty-page functions you've tried to debug, the more the short function becomes your friend.
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.
No. There's still an overhead. It's just very small relative to architectures today. If you were running code on a 486, a different tune would be sung.
Optimizations certainly help, but there's an intentional tradeoff here: expend more CPU cycles to improve application quality and maintainability in the face of increasing complexity. This is a tradeoff we've been making ever since the first high-level language was developed.
I think newer overall systems benefit from the combination of:
Looking at the two sentences:
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.
You have wonder what is meant by "Older" and "Modern", and what language features might effect performance.
If they mean older languages, for example Fortran, then they are completely wrong - older versions of Fortran didn't support local extent, so subroutine calls were very fast, as they didn't require saving the values held by local variables when calls were made. The requirement to save local variables for each nested function call constitutes an overhead in languages such as C, which support recursion. Later versions of Fortran add recursive functions, but you have to explicitly mark the functions as recursive.
So basically "older languages" have less of an overhead. So either it's rubbish, or they are comparing "modern OO languages" with "Older OO languages"
In a traditional OO language, such as Smalltalk ( Smalltalk is the oldest 'pure' OO language, but this also applies the recent Smalltalk inspired languages, such as Ruby and Python; as far as procedure calls go Ruby is very traditional ), every procedure call is potentially a polymorphic method so behaves as though it is looked up by name at runtime when the call is made. With no change to the language, modern implementations of Smalltalk run faster by inlining polymorphic methods which are repeatedly invoked.
But Smalltalk isn't a modern language ( in many ways it's a dialect of Lisp, so its heritage is 1950s even though it only arrived in the 1970s ), and the improvement is made to the implementation, not the language. The same improvement exists in the Sun Java runtime, the Google JavaScript runtime and many common lisp runtimes; both Java and JavaScript are a more recent OO languages than Smalltalk, but the method call optimisation exists despite the features of those languages ( Java's static typing would suggest the use of a static dispatch table, like many C++ implementations have, JavaScript's very late binding and lack of classes make the optimisation a bit harder to implement).
I can't think of a way to read the two sentences which is true.
If you then look at the wider context of the article, it implies that the style of code has changed from long methods to short methods.
Is it then arguing that this Smalltalk code from the 197Os would now be written using much shorter methods in a more recent OO language like Java or C++0x?
enter [ self show. edit Menu show. scrollbar show ]
leave [ document hideselection. editMenu hide. scrollbar hide ]
outside
[editMenu startup => []
scrollbar startup => [self showdoc]
^false]
pendown [ document pendown ]
keyboard [ document keyboard ]
That doesn't seem very likely either. The change came with OO, which is as modern as the Bee Gees.
However, there was a big shift in method size and refactoring into smaller method between procedural to OO code.
Once you've got an object whose fields hold the data you're using it's much easier to pass that one object to a sub-procedure rather than passing a dozen different local variables, and that's probably the strongest reason for small methods being more common in traditional OO, but it's not strongly related to performance nor with modern languages. It's just that it's a lot of work and very error prone to wrangle a 12 double and int arguments in and out of a function in C.
I've been both in the situation of looking at a long chunk of procedural code and creating an object ( or struct in C ) to hold the state to allow it to be refactored, and doing the reverse ( coping lots of fields into local variables and manually inlining shorter methods ) to improve performance ( in Java 1.3 IIRC ). Since you can do that refactoring in ANSI C it's hardly restricted to modern OO languages.