Everyone says that I should make my code modular, but isn't it less efficient if I use more method calls rather than fewer, but larger, methods? What is the difference in Java, C, or C++ for that matter?
I get that it is easier to edit, read and understand, especially in a group. So is the computation time loss insignificant compared to the code tidiness benefits?
Yes, it is irrelevant.
Computers are tireless, near-perfect execution engines working at speeds totally un-comparable to brains. While there is a measurable amount of time that a function call adds to the execution time of a program, this is as nothing compared to the additional time needed by the brain of the next person involved with the code when they have to disentangle the unreadable routine to even begin to understand how to work with it. You can try the calculation out for a joke - assume that your code has to be maintained only once, and it only adds half an hour to the time needed for someone to come to terms with the code. Take your processor clock speed and calculate: how many times would the code have to run to even dream of offsetting that?
In short, taking pity on the CPU is completely, utterly misguided 99.99% of the time. For the rare remaining cases, use profilers. Do not assume that you can spot those cases - you can't.
It depends.
In the glacially-slow world that is Web programming, where everything happens at human speeds, method-heavy programming, where the cost of the method call is comparable to or exceeds the cost of the processing done by the method, probably doesn't matter.
In the world of embedded systems programming and interrupt handlers for high-rate interrupts, it most certainly does matter. In that environment, the usual models of "memory access is cheap" and "the processor is infinitely fast" break down. I have seen what happens when a mainframe object-oriented programmer writes his first high-rate interrupt handler. It wasn't pretty.
Several years ago, I was doing nonrecursive 8-way connectivity blob coloring on real-time FLIR imagery, on what was at that time a decent processor. The first attempt used a subroutine call, and the subroutine call overhead ate the processor alive. (4 calls PER PIXEL x 64K pixels per frame x 30 frames per second = you figure it out). The second attempt changed the subroutine into a C macro, with no loss of readability, and everything was roses.
You have to look HARD at what you are doing and at the environment in which you will be doing it.
First of all: Programs in a higher language is for being read by humans not by machines.
So write the programs so that you understand them. Don't think about performance (if you seriously have perfomance problems then profile your application and enhance the performance where it is needed).
Even if it is true that calling a method or function takes some overhead this does not matter. Today compilers should be able to compile your code into efficient machine language so that the generated code is efficient for the target architecture. Use the optimization switches of your compiler to get the efficient code.
Typically when you would otherwise have a large function and you split it into a lot of smaller ones, these smaller ones will be inlined because the only downside of inlining (repeating the same instructions too much) is not relevant in this case. That means your code will act as if you had written one large function.
If they are not inlined for some reason and this becomes a performance problem, then you should consider manual inlining. Not all applications are networked CRUD forms with huge intrinsic latencies.
There is probably no computation cost. Usually the compilers/JITs for past 10-20 years or so deals with the function inlining perfectly fine. For the C/C++ usually it is limited to 'inlinable' functions (i.e. the definition of function is available for compiler during compilation - that is it is in header of the same file) but current techniques of LTO overcome this.
If you should spent time on optimization depends on the area you are working on. If you deal with 'normal' application that spent most of the time waiting on input - probably you should not worry about optimizations unless application 'feels' slow.
Even in such cases you should concentrate on many things before doing micro-optimization:
O(n) to O(log n) might have much larger impact then anything you could achieve by micro-optimization. List when you need HashSet so you have O(n) lookups when you could have O(1).Even if you do decide that you need to perform micro-optimization (which practically means that your software is used in HPC, embedded or just used by very large number of people - otherwise the additional cost of maintenance overcome the computer time costs) you need to identify the hotspots (kernels) you want to accelerate. But then you probably should:
As a final remark. Usually the only problem you have with method calls is the indirect jumps (virtual methods) which were not predicted by branch predictor (unfortunately indirect jump is the hard case for it). However:
My answer probably won't expand too much on the existing answers, but I feel like my two cents may be helpful.
First off; yes, for modularity, you usually give up some level of execution time. Writing everything in assembly code is going to give you the best speed. That said...
You know YouTube? Likely either the most high-bandwidth site in existence, or second to Netflix? They write a large portion of their code in Python, which is a highly modular language not quite built for top-notch performance.
The thing is, when something is going wrong, and users are complaining about videos loading slowly, there's not many scenarios where that slowness would ultimately be attributed to the slow execution speed of Python. However, Python's quick re-compilation, and its modular ability to try new things without type-checking will probably allow the engineers to debug what's going wrong pretty quickly ("Wow. Our new intern wrote a loop that does a new SQL sub-query for EVERY result.") or ("Oh, Firefox has deprecated that old caching header format; and they made a Python library to set up the new one easily")
In that sense, even in terms of execution time, a modular language can be thought of as faster because once you find what your bottlenecks are, it will likely become easier to reorganize your code to get it working in the best way. So many engineers will tell you that the heavy performance hits weren't where they thought they'd be (and in fact the things they DID optimize were hardly needed; or, didn't even work the way they'd expect!)
Yes and no. As other have noted program for readability first, then for efficiency. However, there are standard practices which are both readable and efficiency. Most code gets run rather infrequently, and you won't gain much advantage from optimizing it anyway.
Java can inline smaller function calls, so there is little reason to avoid writing the functions. Optimizers tend to work better with simpler easier to read code. There are studies that show shortcuts which should theoretically run faster, actually take longer. The JIT compiler is likely to work better the code is smaller and frequently run pieces can be identified and optimized. I haven't tried it but I would expect one large function which is relatively rarely called not to be compiled.
This likely doesn't apply to Java, but one study found larger functions actually ran slower due to requiring a different memory reference model. This was hardware and optimizer specific. For smaller modules instructions which worked within a memory page were used. These were faster and smaller than the instructions required when the function did not fit withing a page.
There are cases where it is worth while to optimize code, but generally you need to profile the code to determine where that is. I find it is often not the code I expected.
