Optimization: .cpp or .obj/.o or .lib/.a

Question

I have this chuck of code that could be placed in a separate library but I'm unsure how that will affect the compiler's ability to optimize.

Option 1: include the code directly in the projects and compile it together with everything else.

Option 2: build the .obj/.o files and simply use them when building the projects.

Option 3: create a static library (.lib or .a) and link with that when building the projects.

Now, my question is: which of these will give the best performance? If you could discuss/explain the consequences of each of the options with regard to compiler optimization that would be super awesome!

Thanks in advance :-)

Answer 1

If by Option 1 you mean #include the code via header files, then the compiler may be able to optimise slightly better than linking multiple objects together, as in Options 2 and 3. This is because the compiler can see the entire source code, rather than just the object code, and may be able to inline functions.

There is no difference between Options 2 and 3, as an archive file - *.a - is just a collection of object files - *.o.

All this being said, The Architecture of Open Source Applications: LLVM implies that you can build LLVM IR code objects, which when linked can be optimised properly, including inlining of functions. So, if you are using clang++, this may be an option.

Answer 2

There's no difference in the optimization a compiler can do. In every case, the object can be built with as much or as less optimization you want.

The only difference you might see, is when you build a shared library. Then you have a call overhead, which you have not, when linking the objects or a static library directly into the executable.

Answer 3

There should be no difference in performance:

An .a file is simply an archive of .o files. They are treated the same by the linker (except that .a files need to be unpacked first).

Directly compiling all sources together will still result in all compilation units be compiled separately, and subsequently linked together. It’s just that the compiler hides this and calls the linker behind your back. Nevertheless, the work is the same as when first compiling the compilation units separately and then linking them together in an explicit step.