2

Does a file structure that is mostly header files (90% of your code being header-only) slow down anything besides compilation?

Some people argue that it could cause inlining of most code in case of speed optimizations and so processor would calculate wrong stats about instruction calls or something like that. Is anywhere shown that it or something similar would happen and so slow down application speed?

Scott Mermelstein
  • 15,174
  • 4
  • 48
  • 76
myWallJSON
  • 9,110
  • 22
  • 78
  • 149
  • If your using a machine and/or compiler built in the 80's or a embedded system this might be serious concern. I use the `boost` library as a header only library in developing some high performance system and boost never seems to be the bottleneck. – andre Jul 15 '13 at 21:41
  • I'll like to add that pre-compile headers could offer a significant speed up if your libraries are stable and do not change often. – andre Jul 15 '13 at 21:45
  • Most projects are mostly header files to the compiler. I had a compiler years ago (Watcom C/C++) that would give you line counts, and they were typically 300 lines of .c and 5000 lines of headers. – user207421 Jul 15 '13 at 23:34

3 Answers3

4
  1. This is possibly a duplicate of Benefits of inline functions in C++?
  2. The practical performance implication depends on many factors. I would not concern myself with it until you actually have a performance problem, in which case I'm sure bigger gains can be obtained by optimizing other things.
  3. Don't keep all your code in headers - if you continue with this trend you will hate yourself later because you will be waiting for your compiler most of the time. LTO is a better approach if you are looking for similar optimizations, and has less of an impact on compile time.
Community
  • 1
  • 1
Iwan Aucamp
  • 1,469
  • 20
  • 21
3

Linking is a concern.

If your libraries are header dominant, then larger intermediate object files may need to be written then read. The linker will then have more symbols to analyze and deduplicate, and some symbols will remain as legal duplicates. This increases your I/O, bloats your binary size, and throws a lot more work at the linker.

One benefit of header dominance is that there tends to be fewer sources to compile and consequently fewer images/objects to link. So header only also has the potential to be faster in this regard (if used correctly).

If your library is going to be visible to many translations, then size and impact on linking should also be an important consideration.

justin
  • 104,054
  • 14
  • 179
  • 226
  • I think what he was referring to by compilation in his original question is compile + link - but this is a valid concern - personally though I have never been in a situation where link time is significant compared to compile time. – Iwan Aucamp Jul 16 '13 at 21:08
0

Not performance but potential bug concern:

From Uses Guidelines : In C++ class member functions declared in class defenition body always get inlined. If class member function has static members this would lead to each inlined function instance having its own static member. This would lead to bugs.

DuckQueen
  • 772
  • 10
  • 62
  • 134
  • 1
    That would be a violation of the language standard, and therefore a *compiler* bug. – user207421 Jul 16 '13 at 13:29
  • @EJP: please provide a refrence to standart (paragraph, frase) – DuckQueen Jul 16 '13 at 14:14
  • 1
    @DuckQueen EJP is right - cloning the data would violate the **One Definition Rule** - http://en.wikipedia.org/wiki/One_Definition_Rule. – justin Jul 16 '13 at 21:26
  • 1
    @DuckQueen c++03/[class.mfct]/2 does specify **... A member function may be defined (8.4) in its class definition, in which case it is an inline member func- tion (7.1.2) ...** - however c++03/[dcl.fct.spec]/2 (7.1.2) goes on to say **... that inline substitution of the function body at the point of call is to be preferred ...** - and since the standard is pretty clear on the behavior of both static members and static local variables I do not think your concern is justified. – Iwan Aucamp Jul 16 '13 at 21:29
  • @justin - I'm not really sure [basic.def.odr] is what ensures correct behavior here - as DuckQueen is saying two different translation units will not share the same storage for the static member. – Iwan Aucamp Jul 16 '13 at 21:36