My question is this: when it call comes down to machine code, to 1s
and 0s, to assembly instructions, should I be at all concerned that my
class-separated code with variety of small-to-tiny functions generates
too much extra overhead?

MY answer is yes, you should. Not because you have lots of little functions (once upon a time the overhead of calling functions was reasonably significant and you could slow your program down by making a million little calls in loops, but today compilers will inline them for you and what’s left is taken care of by the CPU fancy prediction algorithms, so don’t worry about that) but because you will introduce the concept of layering too much into your programs when the functionality is too small to sensibly grok in your head. If you have larger components you can be reasonably sure they are not performing the same work over and over, but you can make your program so minutely granular that you may find yourself unable to really understand the call paths, and in that end up with something that barely works (and is barely maintainable).

For example, I worked at a place that showed me a reference project for a web service with 1 method. The project comprised 32 .cs files – for a single web service! I figured this was way too much complexity, even though each part was tiny and easily understood by itself, when it came to describing the overall system, I quickly found myself having to trace through calls just to see what the hell it was doing (there were also too many abstractions involved,as you’d expect). My replacement webservice was 4 .cs files.

i didn’t measure performance as I figure it would have been roughly the same all in all, but I can guarantee mine was significantly cheaper to maintain. When everyone talks of programmer time being more important than CPU time, then create complex monsters that cost lots of programmer time in both dev and maintenance you have to wonder that they are making excuses for bad behaviour.

It was said somewhere (quote TBD) that up to 70% of all code is made
up of ASM’s MOV instruction – loading CPU registers with proper
variables, not the actual computation being done.

That is what CPUs do though, they move bits from memory to registers, add or subtract them, and then put them back into memory. All computing boils down to pretty much that. Mind you, I once had a very multi-threaded program that spent most of its time context switching (ie saving and restoring register state of threads) than it did working on the thread code. A simple lock in the wrong place truly screwed performance there, and it was such an innocuous bit of code too.

So my advice is : find a sensible middle ground between either extreme that make your code look good to other humans, and test the system to see if it performs well. Use the OS features to make sure its running as you’d expect with CPU, memory, disk and network IO.

Without extreme care, micro optimization such as these concerns leads to unmaintainable code.

Initially it looks like a good idea, the profiler tells you the code is faster and V&V/Test/QA even says works. Soon bugs are found, requirements change and enhancements that were never considered are asked for.

Over the life of a project code degrades and becomes less efficient. Maintainable code will become more efficient than its unmaintainable counterpart
as it will degrade slower. The reason is code builds entropy as it is changed –

Unmaintainable code quickly has more dead code, redundant paths and duplication. This leads to more bugs, creating a cycle of degradation of the code – including its performance. Before long, developers have low confidence that the changes they are making are correct. This slows them down, makes the cautious and generally leads to even more entropy as they address only the detail they can see

Maintainable code, with small modules and unit tests is easier to change, code that is no longer needed is easier to identify and remove. Code that is broken is also easier to identify, can be repaired or replaced with confidence.

SO in the end it comes down to life cycle management and is not as simple as “this is faster so it will always be faster.”

Above all, slow correct code is infinitely faster than fast incorrect code.

To my understanding, as you point out with inline, on lower level forms of code like C++ it can make a difference but I say CAN lightly.

The website sums it up – there is no easy answer. It depends on the system, it depends on what your application is doing, it depends on the language, it depends on the compiler and optimization.

C++ for example, inline can increase performance. Many times it might not do anything, or possibly decrease performance but I’ve personally never encountered that myself though have heard of stories. Inline is nothing more than a suggestion to the compiler to optimize, which can be ignored.

Chances are, if you’re developing higher level programs, the overhead shouldn’t be a concern if there is one at all to begin with. Compilers are extremely smart these days and should handle this stuff anyway. Many programmers have a code-to-live by: don’t ever trust the compiler. If this applies to you, then even slight optimizations you feel are important can be. But, keep in mind, every language differs in this regard. Java does inline optimizations automatically at runtime. In Javascript, inline for your webpage (as opposed to seperate files) is a boost and every milisecond for a webpage might count but thats more of an IO issue.

But on lower level programs where the programmer might be doing a lot of machine code work along with something like C++, the overheard might make all the difference. Games are a good example of where CPU pipelining is critical, especially on consoles, and something like inline can add up a little here and there.

A good read on inline specifically: http://www.gotw.ca/gotw/033.htm

You need to be careful to listen to experienced programmers as well as current thinking.
People who have dealt for years with massive software have something to contribute.

In my experience, here is what leads to slowdowns, and they are not small.
They are orders of magnitude:

• The assumption that any line of code takes roughly as much time as any other.
  For example cout << endl versus a = b + c. The former takes thousands of times longer than the latter.
  Stackexchange has a lot of questions of the form “I’ve tried different ways of optimizing this code, but it doesn’t seem to make a difference, why not?” when there’s a big-old function call in the middle of it.

• The assumption that any function or method call, once written, is of course necessary.
  Functions and methods are easy to call, and the calling is usually pretty efficient.
  The problem is they are like credit cards. They tempt you to spend more than you really want to, and they tend to hide what you spent.
  On top of that, large software has layers upon layers of abstraction, so even if there is only 15% waste at each layer, over 5 layers that compounds to a slowdown factor of 2.
  The answer to this is not to remove functionality or write bigger functions, it is to discipline yourself to be on guard for this problem and be willing and able to root it out.

• Galloping generality.
  The value of abstraction is it can let you do more with less code – at least that’s the hope.
  This idea can be pushed to extremes.
  The problem with too much generality is that every problem is specific, and when you solve it with general abstractions, those abstractions are not necessarily able to exploit the specific properties of your problem.
  For example, I’ve seen a situation where a fancy priority queue class, which could be efficient at large sizes, was used when the length never exceeded 3!

• Galloping data structure.
  OOP is a very useful paradigm, but it does not encourage one to minimize data structure – rather it encourages one to try to hide the complexity of it.
  For example, there is the concept of “notification” where if datum A is modified in some way, A issues a notification event so that B and C can also modify themselves so as to keep the whole ensemble consistent. This can propagate over many layers, and magnify the cost of the modification enormously.
  Then it is entirely possible that the change to A could soon after be undone or changed to yet another modification, meaning that the effort spent on trying to keep the ensemble consistent has to be done yet again.
  Confounding that is the probability of bugs in all these notification handlers, and circularity, etc.
  It is far better to try to keep the data structure normalized, so that any change needs to be made in one place only.
  If non-normalized data cannot be avoided, it is better to have periodic passes to repair the inconsistency, rather than pretending it can be kept consistent with a short leash.

… when I think of more I’ll add it.

This is a change compared to the “old” or “bad” code practices where you have methods spanning 2500 lines, and big classes doing everything.

I don’t think anyone ever thought doing that is a good practice. And I doubt the people that did it did it for performance reasons.

I think the famous quote from Donald Knuth is very relevant here:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

So, in 97 % of your code, just use good practices, write small methods (how small is a matter of opinion, I don’t think all methods should be just few lines), etc. For the remaining 3 %, where performance does matter, measure it. And if measurements show that having many small methods actually significantly slows your code down, then you should combine them into bigger methods. But don’t write unmaintainable code just because it might be faster.

The short answer is “yes”. And, generally, the code will be a bit slower.

But sometimes a proper OO-ish refactoring will reveal optimizations that make the code faster. I worked on one project where we made a complex Java algorithm much more OO-ish, with proper data structures, getters, etc. instead of messy nested arrays of objects. But, by better isolating and restricting access to the data structures, we were able to change from giant arrays of Doubles (with nulls for empty results) to more organized arrays of doubles, with NaNs for empty results. This yielded a 10x gain in speed.

Addendum: In general, smaller, better structured code should be more amenable to multi-threading, your best way to get major speedups.

Among other things, programming is about trade-offs. Based on this fact, I incline to answer yes, it could be slower. But think about what you get in return. Getting readable, reusable and easily modifiable code is easily overweighs any possible drawbacks.

As @user949300 mentioned, it is easier to spot areas that can be algorithmically or architecturally improved with such approach; improving those are usually far more beneficial and effective than not having possible OO or function-calling overhead (which is already just a noise, I bet).

I also imagine that good optimizations can be done to ASM before it is
actually ran on the hardware.

Whenever something likes this crosses my mind, I remember that decades spent by smartest people working on compilers are probably making tools like GCC far better than me at generating machine code. Unless you are working on some sort of microcontrollers related stuff, I suggest you don’t worry about that.

I am assuming that adding more and more functions and more and more
objects and classes in a code will result in more and more parameter
passing between smaller code pieces.

Assuming anything when optimizing is a waste of time, you need facts about code performance. Find where you program spends most of the time with specialized tools, optimize that, iterate.

To sum it all up; let compiler do its job, focus on important things like improving your algorithms and data structures. All the patterns you mentioned in your question exist to help you with that, use them.

P.S.: These 2 Crockford’s talks popped in my head and I think they are somewhat related. First one is super brief CS history (which is always good to know with any exact science); and second one is about why we reject good things.

• The Early Years
• Programming Style & Your Brain

I believe the trends you identify point at a truth about developing software – programmer time is more expensive that CPU time. Thus far, computers have only gotten faster and cheaper, but a tangled mess of an application can take hundreds if not thousands of man-hours to change. Given the cost of salaries, benefits, office space, etc, etc, it’s more cost-effective to have code that might execute a little slower but is quicker and safer to change.

Well 20+ years ago, which I am guessing you are not calling new and not “old or bad”, the rule was to keep functions small enough to fit on a printed page. We had dot matrix printers then so the number of lines was somewhat fixed generally only one or two choices for number of lines per page…definitely less than 2500 lines.

You are asking many sides of the problem, maintainability, performance, testability, readability. The more you lean toward performance the less maintainable and readable the code will become, so you have to find your comfort level which can and will vary for each individual programmer.

As far as code produced by the compiler (machine code if you will), the larger the function the more opportunity for needing to spill intermediate values in registers to the stack. When stack frames are used the stack consumption is in larger chunks. The smaller the functions the more opportunity for the data staying more in registers and the less dependence on the stack. Smaller chunks of stack needed per function naturally. Stack frames have pros and cons for performance. More smaller functions means more function setup and cleanup. Of course it also depends on how you compile, what opportunities you give the compiler. You may have 250 10 line functions instead of one 2500 line function, the one 2500 line function the compiler is going to get if it can/chooses to optimize across the whole thing. But if you take those 250 10 line functions and spread them across 2, 3, 4, 250 separate files, compile each file separately then the compiler wont be able to optimize out nearly as much dead code as it could have. the bottom line here is there are pros and cons to both and it is not possible to put a general rule on this or that is the best way.

Reasonable sized functions, something a person can see on a screen or page (in a reasonable font), is something they can consume better and understand than code that is quite large. But if it is just a small function with calls to many other small functions that call many other small functions you need several windows or browsers up to understand that code so you didnt buy anything on the readability side.

the unix way is to make using my term, nicely polished lego blocks. Why would you use a tape function this many years after we stopped using tapes? Because the blob did its job very well and on the back side we can replace the tape interface with a file interface and take advantage of the meat of the program. Why re-write cdrom burning software just because scsi went away as the dominant interface replaced by ide (then to come back later). Again take advanatage of the polished sub blocks and replace one end with a new interface block (also understand the hardware designers simply tacked an interface block on the hardware designs to in some cases making a scsi drive have an ide to scsi interface. To shorten this, build reasonable sized polished lego blocks each with a well defined purpose and well defined inputs and outputs. you can wrap tests around those lego blocks and then take the same block and wrap user interface and operating system interfaces around the same block and the block, in theory being well tested and well understood wont need to be debugged, just the additional new blocks added on each end. so long as all of your blocks interfaces are well designed and the functionality well understood you can build a great many things with minimal if any glue. just like with blue and red and black and yellow lego blocks of known sizes and shapes you can make a great many things.

Every individual is different, their definition of polished and well defined and tested and readable vary. It is not unreasonable for example for a professor to dictate programming rules not because they may or may not be bad for you as a professional, but in some cases to make the job of reading and grading your code easier on the professor or grad student assistants…You are equally likely, professionally, to find that each job may have different rules for various reasons, usually one or a few people in power have their opinion on something, right or wrong and with that power they can dictate that you do it there way (or quit, get fired, or somehow come to power). These rules are as often opinion based as they are based in some kind of fact about readability, performance, testability, portability.

Depends how smart your compiler is. Generally, trying to outsmart the optimizer is a bad idea and may actually rob the compiler of opportunities to optimize. For starters, you probably don’t have any clue whatsoever what it can do and most of what you do actually influences how well it does that too.

Premature optimization is the notion of programmers trying to do that and ending up with hard to maintain code that wasn’t actually on the critical path of what they were trying to do. Trying to squeeze out as much CPU as possible when most of the time your app is actually blocked waiting for IO events, is something I see a lot for example.

The best is to code for correctness and use a profiler to find actual performance bottlenecks, and fix those by analyzing what is on the critical path and whether it can be improved. Often a few simple fixes go a long way.

THE ANSWER (in case you missed it)

Yes, you should care, but care about how you write the code, and not about performance.

In short

Do not care about performance

In the context of the question, smarter compilers and interpreters already take care of that

Do care about writing maintainable code

Code where maintenance costs are on the level of reasonable human comprehension. i.e. don’t write 1000 smaller functions making code incomprehensible even if you understand each one, and don’t write 1 god object function that is too large to understand, but write 10 well-engineered functions that make sense to a human, and are easy to maintain.

[computer-time element]

Does Refactoring towards Looser Coupling and Smaller Functions affect Speed of Code?

Yes, it does. But it is up to interpreters, compilers, and JIT-compilers to strip down this “seam/wiring” code, and some do it better than others, but some don’t.

Multiple-file concern adds to I/O overhead, so that affects speed quite a bit as well (in computer-time).

[human-speed element]

(And should I care?)

no you shouldn’t care. Computers and circuits are plenty fast these days, and other factors take over, such as network latency, database I/O, and caching.

So 2x – 4x slow down in the native code execution itself will often get drowned out by those other factors.

As far as multiple-file loading, that is often being taken care of by various caching solutions. It may take more time to load things up and merge them up the first time, but for every next time, for static files, caching does work as if a single file is being loaded. Caching comes as a solution to multiple-file loading.