0

(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?

aragaer
  • 656
  • 5
  • 12
  • 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

3 Answers3

9

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 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
  • It means I can spend as much time as I want just playing with code (and I do love playing with code). – aragaer Feb 19 '14 at 21:16
  • @aragaer Arranging your code in a modular, easy to understand way will make it easier for you to play with it. Well written code will benefit even a team of one. Maybe if you just want to write a one-off, try something and discard the code... in that case you probably can disregard all best practices. – Andres F. Feb 19 '14 at 21:19
  • In case when it is "readability vs performance" I actually tend to try completely different approach. That's what I call "playing with code" here. – aragaer Feb 19 '14 at 21:21
  • @aragaer Well, if you've found a better way to handle readability vs performance, you are not going to share your code with anyone else, and it isn't going to be used for anything that requires industry best practices, testing or verification, then suit yourself... I guess :) – Andres F. Feb 19 '14 at 21:33
3

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.

Doval
  • 15,347
  • 3
  • 43
  • 58
0

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.

maaartinus
  • 2,633
  • 1
  • 21
  • 29