6

A question was asked about whether namespace and folder structure would affect performance of an assembly in C#. The answers were very useful, but where specific to C# and the CLR.

How will the namespace and folder structure affect the performance of an assembly if it is written in C++ with gcc? What's the situation on other OSes, such as Linux or Mac OS?

If there are any significant performance issues, what should I do or avoid doing to maximize performance?

Community
  • 1
  • 1
The Floating Brain
  • 896
  • 8
  • 24

2 Answers2

10

Neither your directory hierarchy nor namespaces will affect your compiled code. The code your compiler will generate will be the same. This goes for all compilers and all OS's.

Kyle
  • 1,111
  • 1
  • 12
  • 27
  • 1
    It's not 100% correct that namespaces do not affect performance. Using an anonymous namespace can improve performance in your code. See http://stackoverflow.com/a/25565298/351771 – xioxox Aug 29 '14 at 09:25
  • Interestingly enough, though it shouldn't, this presentation seems to differ, I immediately thought of this question after watching it, considering answering my own question. https://www.youtube.com/watch?v=r-TLSBdHe1A – The Floating Brain Feb 09 '20 at 11:46
9

To expand a bit on what Kyle said:

Namespaces are nothing more than a syntactic way for the user and the compiler to put names in different buckets. They exist to allow you to use more common and appropriate names for things without having to worry about conflicts with someone else. std::vector is a different type from a mathematical vector class. They can share the same name so long as they're in different namespaces.

As far as the compiler is concerned, a function in a namespace is no different from a function anywhere else. It just has a funny name. Indeed, compilers are allowed the freedom to do what's called "name mangling": when the compiler sees std::vector<int>, it can actually convert that into something like __std~~vector~t~~int32_t~~__ or whatever. The mangling algorithm is chosen so that no user-defined name in the global namespace can match the name used by the namespace mangler. Thus all namespace-scoped names are separate from names in other namespaces, even the global one.

Basically, the first step in the compilation process is to effectively eliminate namespaces. Therefore, later compiler steps have no clue what namespace something is even in. So they cannot generate code from it. And thus, namespaces cannot have any effect on the execution speed of compiled code.

Folders... cannot possibly matter. After compilation, you get a single executable, library, or DLL. If a compiler ever did any code generation based on the location of the source files, you would be well advised to avoid that compiler like the plague. The compiler writers would have to be trolling their users to make that happen.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • 2
    There's a very small exception to that folder statement; variables in unnamed namespaces are mangled such that their internal name is unique for every source file. That means that `foo` from file1.cpp must be distinct from `foo` in file2.cpp, and also from `foo` in subdir/file1.cpp. Therefore you'd expect mangled names like `subdir__file1__foo`. – MSalters Feb 17 '12 at 09:07
  • There can be quite some difference in specific situations between `ld *.o` and `ld b.o a.o` though, since those two calls result in a different icache layout. Although that's only indirectly influenced by the folder structure (and has nothing to do with the compiler, but linker - so a bit OT though still pretty non-intuitiv) – Voo Feb 17 '12 at 09:14