In Computer Science field, I have noticed a notable shift in thinking when it comes to programming. The advice as it stands now is
- write smaller, more testable code
- refactor existing code into smaller and smaller chunks of code until most of your methods/functions are just a few lines long
- write functions that only do one thing (which makes them smaller again)
- create more files (for decomposition purposes, layers, architecture, classes, OO)
This is a change compared to the "old" or "outdated" coding practices where you have methods spanning 2500 lines, and big classes doing everything.
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?
While I am not exactly familiar with how OO code and function calls are handled in ASM in the end, I do have some idea. I assume that each extra function call, object call, or include call (in some languages), generate an extra set of instructions, thereby increasing code's volume and adding various overhead, without adding actual "useful" code. I also imagine that good optimizations can be done to ASM before it is actually ran on the hardware, but that optimization can only do so much too.
Hence, my question -- how much overhead (in space and speed) does well-separated code (split up across hundreds of files, classes, and methods) actually introduce compared to having "one big method that contains everything", due to this overhead?
UPDATE for clarity:
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.
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. In my case, you load up CPU's time with PUSH/POP instructions to provide linkage and parameter passing between various pieces of code. The smaller you make your pieces of code, the more overhead "linkage" is required. I am concerned that this linkage adds to software bloat and slow-down and I am wondering if I should be concerned about this, and how much, if any at all, because current and future generations of programmers who are building software for the next century, will have to live with and consume software built using these practices.
UPDATE: Multiple files
I am writing new code now that is slowly replacing old code. In particular I've noted that one of the old classes was a ~3000 line file (as mentioned earlier). Now it is becoming a set of 15-20 files located across various directories, including test files and not including PHP framework I am using to bind some things together. More files are coming as well. When it comes to disk I/O, loading multiple files is slower than loading one large file. Of course not all files are loaded, they are loaded as needed, and disk caching and memory caching options exist, and yet still I believe that
loading multiple files takes more processing than
loading a single file into memory. I am adding that to my concern.
UPDATE: Dependency Inject everything
Coming back to this after a while.. I think my question was misunderstood. Or maybe I chose to misunderstand some answers. I am not talking about micro-optimizing as some answers have singled out, (at least I think calling what I am talking about micro-optimization is a misnomer) but about the movement of "Refactor code to loosen tight coupling", as a whole, at every level of the code. I came from Zend Con just recently where this style of code has been one of the core points and centerpieces of the convention. Decouple logic from view, view from model, model from database, and if you can, decouple data from the database. Dependency-Inject everything, which sometimes means just adding wiring code (functions, classes, boilerplate) that does nothing, but serves as a seam/hook point, easily doubling code size in most cases.
UPDATE 2: Does "separating code into more files" significantly affect performance (at all levels of computing)
How does philosophy of
compartmentalize your code into multiple files impact today's computing (performance, disk utilization, memory management, CPU processing tasks)?
I am talking about
In a hypothetical yet quite real not so distant past, you could easily write one mono-block of a file that does has model and view and controller spaghetti or not-spaghetti-coded, but that runs everything once it is already loaded. Doing some benchmarks in the past using C code I found out that it is MUCH faster to load a single 900Mb file into memory and process it in large chunks than it is to load a bunch of smaller files and process them in a smaller peace-meal chunks doing the same work in the end.
.. And Now*
Today I find myself looking at code that shows a ledger, that has features like .. if an item is an "order", show order HTML block. If a line item can be copied, print HTML block that displays an icon and HTML parameters behind it allowing you to make the copy. If the item can be moved up or down, display the appropriate HTML arrows. Etc. I can, through Zend Framework create
partial() calls, which essentially means "call a function that takes your parameters and inserts them into a separate HTML file that it also calls". Depending on how detailed I want to get, I can create separate HTML functions for the tiniest parts of the ledger. One for arrow up, arrow down, one for "can I copy this item", etc. Easily creating several files just to display a small part of the webpage. Taking my code and behind-the-scenes Zend Framework code, the system/stack probably calls close to 20-30 different files.
I am interested in aspects, the wear and tear on the machine that is created by compartmentalizing code into many smaller separate files.
For example, loading more files means having them located in various places of the file system, and in various places of physical HDD, which means more HDD seek and read time.
For CPU it probably means more context switching and loading various registers.
In this sub-block (update #2) I am interested more strictly in how using multiple files to do the same tasks that could be done in a single file, affect system performance.