(I see there are a lot of similar questions, but answers are not really what I am interested at.)

The thing that is bugging me is indirection. If I'm writing something, I do tend to inline as much stuff as possible. I might be less strict about it in compiled language hoping that compiler will do all the inlining for me. Still adding layers of indirection feels to me like "I'll just add some more burden onto user in runtime so that I could have nicer code here" - something that could be solved with either a comment or a different design (which I would actually prefer but it would take some more time). Seeing a small function that is used only once I have to actually fight the urge to inline it. Having a multitude of single-use classes makes me want to create a different (and usually totally procedure-oriented) solution.

How bad is that? How many layers of indirection are actually OK to have?

  • Well, inline as much as possible and avoiding indirection might be good if you're programming on a performance sensitive context (e.g. a toaster). But do that on a project where multiple people might have to look at your code and they will rip your heart out of your chest. Anyway if you think that using for example a function in an if instead that inlining it is a problem that you're probably overestimating the users. Users are not robot like creature able to see a difference in the execution in the order of nanoseconds. – Fabio Marcolini Feb 19 '14 at 22:07
  • Calling and returning from a function is just a few standard instructions (push parameters, push return address, etc). Assume an average of one instruction per clock cycle. You have a 1-3 Ghz clock unless you're programming a microprocessor (an iPhone 5 is 1.3Ghz). That should give you an idea of how silly it is to try to optimize speed by reducing the number of function calls. Never mind that if you're using a compiler, then the compiler will probably inline for you anyway. – user16764 Feb 19 '14 at 23:49

There is no question that indirection (of the type you describe) is for the programmers benefit. What you may not be considering is this:

  1. Programmer time is very expensive, but
  2. Method calls are not.

Nicer code isn't just a conceit; it has profound practical concerns. Every minute that you spend comprehending a piece of code that you didn't refactor into a method (accompanied by its own small collection of unit tests to prove that it still works) is one less minute that you can spend making improvements to the software or adding new features.

| improve this answer | |
  • What if I'm writing my own project? Not feature-rich, but I definitely want it polished. – aragaer Feb 19 '14 at 20:49
  • 1
    You mean as opposed to someone else's project? There isn't any difference. – Robert Harvey Feb 19 '14 at 20:50
  • As opposed to commercial project where I'm actually paid for my working time. – aragaer Feb 19 '14 at 20:50
  • 2
    Ah. Well, your own time is priceless, regardless of how much or how little you get paid. – Robert Harvey Feb 19 '14 at 20:51
  • 1
    @aragaer - if it's your project and not feature-rich, what difference does it make? I'm sure there are best practices for bridge design, but if no one is ever going to use it, does any of that matter? – JeffO Feb 19 '14 at 21:15

There's a good reason Knuth said premature optimization is the root of all evil:

  1. If your program isn't correct, it doesn't matter how fast it runs.
  2. Most performance gains come from optimizing a small amount of code (the 80-20 rule).
  3. The compiler is probably better at inlining and other such mechanical optimizations than you.

Write for correctness and clarity first. Measure. Decide if you actually have a performance problem. If you do, find the bottleneck. Then you may optimize.

| improve this answer | |
  • I am not really bothered when I can rely on compiler for inlining and discarding all the overhead stuff. Java on the other hand... – aragaer Feb 19 '14 at 21:39
  • 4
    ... does similar optimizations in the JIT. – Robert Harvey Feb 19 '14 at 21:41
  • 1
    … and the JIT compiler can inline stuff that AOT compilers (like typical C++ compilers) can't. – Jörg W Mittag Feb 20 '14 at 2:17

Seeing a small function that is used only once I have to actually fight the urge to inline it.

That's bad. It's usually bad for readability and sometimes also bad for performance.

The following is rather Java specific, but may apply to other compilers working with statistics.

If you don't inline a method, the compiler may chose to do it or not. If the method gets called rarely, it won't get inlined and it doesn't make the code larger. This leaves more room for inlining of more important methods and also loop unrolling.

If you inline it, it can't be "out-lined" and can hinder the optimizations. This is no theory, see e.g. the comment at line 269 of this library class.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.