For profiling: usually as a first pass I turn to PG. :) Seriously though, add '-pg' to your CFLAGS and LDFLAGS, recompile, run, and look at the output in gprof. It's a pretty good way to easily identify bottlenecks. You can pipe the output to dot and graph the call graphs, etc. -- but I've found that less useful than running the code that I'm trying to make more performant and studying the first 20-30 lines of the gprof output.
But I could never really get them to work personally in practice. Though I learned a lot about what good integration at the terminal level could look like by browsing them. At some point, I hacked together vim and gdb integration pretty well for my purposes (or I should say, improved on the clewn project. I'm pretty happy with it). I wonder if others have done similar things. Anyway, I'm curious what others say as well.
http://sourceware.org/binutils/docs/gprof/Compiling.html#Com...
There are better alternatives as well. But adding -pg first is just so easy, and usually (I've found for my stuff) is enough...
For code discovery: I've experimented with strace as others mention (and ltrace). And there are awesome things like Fenris in theory:
http://lcamtuf.coredump.cx/fenris/devel.shtml
But I could never really get them to work personally in practice. Though I learned a lot about what good integration at the terminal level could look like by browsing them. At some point, I hacked together vim and gdb integration pretty well for my purposes (or I should say, improved on the clewn project. I'm pretty happy with it). I wonder if others have done similar things. Anyway, I'm curious what others say as well.