Additional function / method definitions increase program memory?

Question

In C ++, does the definition of additional methods or functions that are not used lead to an increase in memory or a slower execution speed?

Basically, I have several methods for debugging a utility in a class, none of which are required for normal use of the class. Will it matter in terms of memory size or speed, do these definitions remain or not if they are never used? For instance:

class myClass { public: //Something the user of this class would use int doSomething() {...} //Something used solely to make sure I wrote the class properly bool isClassValid() {...} }; ... myClass classInstance(); myClass.doSomething(); 

Answer 1

Note that most operating systems do not always store all code in memory. Since the code is persistent, the OS can always load it from a file on demand, as it will load dynamic data from swap. But this does not mean that unused code is never loaded, since the OS does not load it with individual methods, but with pages. In other words, it is very difficult to predict which parts of your code segment actually go into memory unless you have very deep knowledge about your OS and the structure of the code segment. The only thing that can be said for sure is that it is possible that your code consumes less physical memory than its actual size.

Regarding the speed of execution, I do not think the answer. This can increase the download speed of the application, but when the code is executed, no one cares about how big it is, and it absolutely does not affect the speed. That is, if you do not come close to your memory limit, and the OS starts to change a lot, and everything becomes very slow.

As already mentioned, the compiler can optimize your code. But you can also do this yourself using #ifdefs for your debugging methods, and this is usually recommended.

Answer 2

Your methods generate code. This code will exist somewhere. When your executable is created, it is likely to exist in your executable. This will increase the size of the executable, increase the load time, and may affect its behavior in the cache. Therefore, the answer is yes.

Except ... It gets dirtier.

A good compiler and a good linker can interact so that any code that you are not actually using is not embedded in your executable. The granularity of this varies, but can go all the way to individual functions (and perhaps even lower in some languages). If the compiler can signal that this method is never called, and the linker is smart enough to bring the code at the function level, then the answer will change to "no."

So, in short, the answer is yes or no depending on the many factors that you will have to research related to the tools you use and the platform you work on.

Answer 3

Unused methods are usually present in the executable unless you tell the linker to find them and delete them.

For example, on a Mac, you can pass -dead_strip to ld to remove such dead code. If you use Windows using Visual C ++, you can pass /OPT:REF to link.exe (I suppose Visual Studio automatically sets your project to pass this option in release builds, but not Debug builds.)

Answer 4

Determining whether the code is unused or not is a rather difficult problem. Just write a welcome program, a static link to it with glibc, and use objdump to look at all the unwanted files that fall into your binary. The vast majority of this code is not used, but it is referenced in ways that make it difficult or impossible for the compiler or linker to optimize it. If you are not the author of the library, you work very hard not to introduce such a dependency, unused functions / methods will be empty places, and there are probably a lot of them. I suspect this is even more complicated in C ++ than in C.