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 :-)

What do you mean in option 1? Just including the cpp files in all projects, or using a header-only approach? — Luchian Grigore, Mar 08 '13 at 16:39
What do you mean with _'best performance'_? When the compiler builds the binaries, or when you run the artifacts? — πάντα ῥεῖ, Mar 08 '13 at 16:41
@LuchianGrigore I mean include the cpp files in all projects. — PGPoulsen, Mar 08 '13 at 23:14
@g-makulik By "best performance" I mean running the artifacts. — PGPoulsen, Mar 08 '13 at 23:15
@PGPoulsen you'd probably get your symbols defined multiple times then. — Luchian Grigore, Mar 08 '13 at 23:15

score 2 · Answer 1 · answered Mar 08 '13 at 16:40

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.

score 1 · Accepted Answer · answered Mar 08 '13 at 16:41

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.

score 0 · Answer 3 · answered Mar 08 '13 at 16:55

0

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.

answered Mar 08 '13 at 16:55

Alex Chamberlain

4,147
2
22
49

This answer is mostly obsolete as all modern compilers perform link-time optimisation. – Konrad Rudolph Mar 08 '13 at 18:53
@KonradRudolph I didn't think they could inline functions at link time? – Alex Chamberlain Mar 08 '13 at 21:54
They definitely can ([and definitely do](http://stackoverflow.com/q/5987020/1968)). – Konrad Rudolph Mar 08 '13 at 22:56
@KonradRudolph Ah but as I (didn't) say, you need the -flto flag on gcc/clang? – Alex Chamberlain Mar 08 '13 at 23:00

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

3 Answers3