pprof tells me that getaliasbyname_r() occupied 56% of cpu time?

Question

I'm using google-perftools to profile my program written in C++ and compiled with g++4.5.2. pprof tells me that getaliasbyname_r() occupied 56% of cpu time! What on earth does getaliasbyname_r() do? Why does it take so much cpu time? Is there a way to alleviate this problem? Thanks. The compliation flags were: -O3 -DNDEBUG -Wall -Wno-deprecated -Wno-sign-compare. System: ubuntu 11.04.

Sorry for not making the question clear. I didn't directly use getaliasbyname_r() in my code. In the call graph generated by the profiling tool "pprof", I can see the tree "start-->_libc_start_main-->main-->..." counts about 44% cputime. Besides this big tree, there is another ioslated single-node tree in the call graph --- getaliasbyname_r. As showed in the graph, it didn't call, nor called by any other functions. I googled this function and was led to http://linux.die.net/man/3/getaliasbyname_r. But that didn't help much. I still have no idea about how getaliasbyname_r() was invoked and why it took so much cputime. Does this question make sense now?

In reply to Adrian: Thank you for your reply. The total run time was about 28 seconds. The profiler samples at rate of 100/sec. So there were about 2800 samples in total. About 1500 fell in getaliasbyname_r(), coming up with a function written by me (caught about 450 samples).

Answer 1

From what I could find the getaliasbyname_r uses something called Name Service Switch which seems to be some remote service (a bit like DNS).

Second thing is that the time measured here seems to ba walltime and not the actual cpu usage.

So my guess would be that getaliasbyname_r simply waits for the response from some network service and this eats a lot of time and cpu is actually idle most of that time (the last part is not true in a most of operating systems as cpu will just take care of other tasks, but your application is "stuck" in getaliasbyname_r untill a response comes back from NSS).

Answer 2

This problem often happens if you don't have symbols for libc6. getaliasbyname_r is exported from libc6, but many internal functions are not, and many of these internal functions are called indirectly by your code and appear after getaliasbyname_r in the binary.

Therefore, when the profiler does symbol lookup it misattributes the time to the wrong function. Oops.

The solution is to install the symbols and then try again. http://randomascii.wordpress.com/2013/01/08/symbols-on-linux-part-one-g-library-symbols/