We have a huge binary and which has constants defined in namespace ex say header1.h:
namespace One
{
namespace Two
{
const String TEST_DATE_TIME = "DDMMYYYY"; // Line number say 32
// ................ Around 2500 such constants ..........
}
}
The problem is that when we run the binary with instrumentation (-finstrument-functions and _cyg* functions) we see methods like below in our report – are they not declared in data segment:
__tcf_2275,header1.h: 32
Does it means that during execution the compiler is spending some time creating the namespace constants – but why? I do not see the same behavior in a sample file (declaring a constants in a namespace).
Further –
nm a.out| grep __tcf_ | more
000000000807acf8 t __tcf_1234
000000000807ad60 t __tcf_1456
............................
000000000816ddd0 t __tcf_1125
............................
addr2line -Cfe a.out 0x807acf8 0x807ad60
__tcf_2275
header1.h:2322
__tcf_2274
header1.h:2321
Definitely we can state that during execution the namespace constants are constructed by compiler. How i) can we reduce them for execution overhead and ii) why are the _tcf defined as ‘t’ section?
You’re definitely messing with compiler and what/when he’s working.
If you define something as a
const String TEST = "something";you’re essentially creating aStringobject (whatever string that is) unlessStringis just a define forchar *. So, before your program is run, the constructor for each of these objects is run (this isn’t and can’t be done at compile time, so it has to happen at run time).I don’t know how you’re using these constants, but if they’re used with
const char*only later on, you should be able to improve performance a lot, by simply listing those:This might however create additional overhead later on if you’re trying to use these as some kind of
Stringobject again. It’s essentially “work to be done at startup” vs. “work to be done when using them”. The const won’t say there’s no work involved (as with const literals or const integral values).As for the second part of the question you’ll have to wait for someone else to explain this, as I’m not that familiar with it. Although you won’t see this code in the
.datasection as it’s dynamically allocated at run time (and code to be run). The string literals used should be in.datathough.