Is it possible to use gprof to line-profile a single function in C++?
Something like:
gprof -l -F function_name ...
, which does not seem to work.
That can be done easily with valgrind. It is a wonderful tool if you have the chance to use it in your development environment. It even have and graphical interface kcachegrind.
Try using options with [symspec] to filter the results. gprof 2.18.0 says that -F and -f are deprecated and to use symspec instead.
Also, -l may not work with binaries compiled with newer versions of gcc. Try gcov instead.
Are you looking for a suspected performance problem? If you have a preconception of where it is, chances are it's not there. If you really want to find performance problems, first you may need to look beyond some myths perpetuated by gprof.
Related
I have a large C++ project of hundreds of files with a CMake build system. How can I use GCC's -ftime-report option but get a single summary for the full build?
I am looking to improve build times and this would be helpful to know where to focus the effort.
You would need to implement that manually by parsing the output somehow.
A good way to get a higher level overview is to use Ninja and parse the .ninja_log file:
https://github.com/ninja-build/ninja/issues/1080#issuecomment-255436851
Also see https://github.com/nico/ninjatracing. Chromium uses tools like that to keep track of build times.
Update:
-ftime-report is simply not suitable for this task as it's meant for compiler devs. Use clang and https://github.com/aras-p/ClangBuildAnalyzer for this.
gcc is far from supporting -ftime-trace: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396
I have a larger C++ programm with lot of templates which i want to debug. Unfortunately gdb takes several minutes to read the symbols.
http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html contains lots of options for debugging.
Which options would you suggest to make gdb faster/more usable.
Update: It looks like the slow down is caused by libtool. If gdb is launched via libtool --mode execute it is slow. If gdb is launched gdb .libs/foo it is reasonable fast. Any ideas why is much slower?
Update: Another suggestion was -fvisibility=hidden see http://gcc.gnu.org/wiki/Visibility
Sometimes using -fdebug-types-section can make things a bit faster. It isn't guaranteed though.
Several minutes to load ... I wonder how big this executable is. If I were desperate I might try only compiling selected modules with debug info. Or perhaps look to see if it is a gdb bug. If it is split into an executable and some shared libraries, and some parts don't change very often, you could also look into using the "gdb index" feature (see the manual) to speed up the loading of debuginfo for those modules.
I'm trying to debug a program that uses DWARF-4 but my gdb is too old and only understands DWARF-2.
I can't update gdb and I can't recompile, so I need a way to convert them, maybe with some binutils tool?
I have never heard of a tool that does this.
If this were my problem I would probably hack up either objcopy or dwz to do it.
I wonder why you can't update gdb though. It isn't hard to build your own.
I have a project containing C/C++ files. I'd like to build it without using make. What are my options? I'd like cross platform solutions if possible.
I've used SCons and it is very good.
SCons is an Open Source software construction tool—that is, a next-generation build tool. Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache. In short, SCons is an easier, more reliable and faster way to build software.
I've also looked at cmake but have not seriously used it.
Well, you're always going to need some way to invoke the compiler. If it's a trivial project, you can usually just stick all the .C filenames on the command line of the compiler and get some kind of output.
Or you can use a batch file / shell script instead of a makefile, but it would be less 'cross-platform' than a makefile and much less useful.
You should probably explain your motivations more clearly.
Since you're going to use Boost anyways (right?) Boost.Jam might be an option.
I already used WAF in some of my projects and it worked out quite well.
If you are familiar with python...
A common alternative is to write python scripts to compile your code.
How are you editing you code? Can that system also build it for you?
Visual Studio, Eclipse, XCode, KDevelop? :-)
I'm developing an application in C++ on Windows XP, using Eclipse as my IDE, and a Makefile-based build system (with custom tools to generate the Makefiles). In addition, I'm using LZZ, which allows me to write a single file, which then gets split into a header and an implementation file. I'm using TDM's port of GCC 4.
What tools or techniques could I use to determine exactly how much time each part of the build process takes, and why it is slow?
Of particular interest would be:
How much time does make need to figure out to parse the Makefiles, figure out the dependencies, check the timestamps, etc?
How much time does Eclipse need before and after the build?
How much time does GCC spend on parsing system and boost headers?
P.S.: This is my home project, so expensive tools are out of reach for me, but could be documented here anyway if they are particularly relevant.
Since Make and GCC are very verbose about what they're doing, a very crude way to get a high-level overview of time spent is to pipe make's output through a script that timestamps each line:
make | perl -MTime::HiRes -pe "printf '%.5f ', Time::HiRes::time()"
(I'm using ActivePerl to do this, but from what I gather, Strawberry Perl may now be the recommended Perl version for Windows.)
Reformat or process the timestamps to your liking.
To get more details about GCC in particular, use the --time-report option.
To find out how much overhead Eclipse adds, use a stopwatch to time builds from Eclipse and from the command line.
if you are using boost, most likely most of time is spent in template instantiation and subsequent optimization. You can tell GCC to report time spent, -time-report (UNIX option, might be something else on Windows GCC)
and if you are trying to speed up your compilation time, disable optimization, -O0 (last letter is number zero, first letter is capital o)
Try SparkBuild, a free gmake/nmake replacement that can generate an annotated build log with precise timing information for every job in the build. You can load that file into SparkBuild Insight to get a graphical overview of where the time goes.
See this blog for an example of how to use it.
There is a version of GNU make called remake that provides profiling information.