views:

122

answers:

3

I've read a lot of the posts here giving profiling advice but I need to ask this.

From what I can tell, visual c++ express doesn't generate a debugging file that is used by profiler

programs. I tried AMD Codeanalyst and it seemed to work fine except none of the routines in my

program were identified. -just a lot of "unidentified modules".

I'm new to c++. I'm used to the simple profiler used by python. Simple, I assume, because the

language is interpreted.

I appreciate any insights.

ps. is the rotation of the steering wheel the derivative of the rotation of the car?

A: 

Are you sure? IIRC, Visual Studio Express can create the .PDB file, though you might have to ask it to generate debugging information for you if you are using a release build. (It has to -- otherwise Visual Studio's debugger wouldn't work!)

Billy ONeal
Well, VSE does create some .pdb files. I'll have to mess around some more with Codeanalyst. Visual Studio's debugger doesn't work with VS express.
Peter Stewart
@Peter Stewart: Err.. yes, VS's debugger works in VS express. You can set a breakpoint and run the program and it will operate correctly.
Billy ONeal
Pardon me. Yes you're right, I was thinking of VS's profiler.
Peter Stewart
A: 

It isn't hard to write your own profiler. Or you could pick up an open source that has some testing behind it. You might want to look at my own open source profiler, called cRunWatch

ravenspoint
That looks like a neat profiler, and I like the unittesting program as well. I'll look at it further.
Peter Stewart
+2  A: 

First, the polar angular velocity of the car should be proportional to the speed of the car and to the angular position of the steering wheel (to a first approximation).

Second, there's hardly a professor or blogger or book author who will tell you this, but if you want to see what the code is doing and optimize it, the hands-down simplest way is this.

Added: Programmers have a strong tendency to assume that any automated profiling tool will do a better job than the manual technique, but that depends on the details of exactly what they do. Most of them implement what's popular rather than what is most effective. The result is some performance problems being missed, putting a cap on the speedup you can get. Here is a list of common misconceptions that result in failing to find performance problems.

Some profilers do get it nearly right, including RotateRight/Zoom and LTProf.

Mike Dunlavey
I don't know about professors, bloggers or authors, but that's exactly how oprofile for linux works. Although the sampling is done automatically, many times a second.
Mike Seymour
@Mike Seymour: You might think so, but it's pretty complicated, and following the doc, it appears to suffer from many of the issues outlined here: http://stackoverflow.com/questions/1777556/alternatives-to-gprof/1779343#1779343
Mike Dunlavey
@Mike Seymour: ... It needs to 1) get random stack samples of a thread even during I/O, 2) be able to ignore samples during user input or better let user control sampling by hot-key, 3) report per line (not per function) percent of samples containing that line (ignoring recursion), 4) ideally let user see individual stack samples. Finally, samples need not be taken in large numbers or at high frequency. In fact, **lsstack** is a perfectly useful way to take them.
Mike Dunlavey
@Mike Seymour: ... For example, any problem whose elimination would save 10% or more of execution time can be found pretty reliably in 20 samples. Not measured accurately - *found* accurately.
Mike Dunlavey
Yeah, pausing is a surprisingly effective technique. I've fixed several slow processes this way.
Steven Fisher
@tewha: Right. I've tried building tools to semi-automate this (along the lines of Zoom), but there's something about getting your fingers right in the code that can't be beat, like being able to read the *why* right off the stack, or being able to see variables as well as the stack.
Mike Dunlavey