Good free profiler that supports MingW32 please?

Question

I asked in another thread, how to profile my stuff, and people gave me lots of good replies, except that when I tried to use several of free profilers, including AMD Codeanalyst for example, they only support Microsoft PDB format, and MingW is unable to generate those.

So, what profiler can help me profile a multi-threaded application with Lua scripting and is compiled with MingW?

EDIT: gprof is crap, the awnser that says why I don't want it, is right on the spot... If I get all the functions that it litsts as troublesome, NONE of them are related to the issue that I have (there are a certain action that causes a massive slowdown, and I can't figure why, and gprof can't figure it either)

Answer 1

Does gprof not do it?

I thought MingW provided a gprof version to go with it.

Answer 2

If you want to profile Lua scripting, I could suggest using the LuaProfiler: http://luaprofiler.luaforge.net/manual.html. It works quite nicely.

I would strongly suggest implementing some sort of timers or your own profiler to get a simple profiling tool. A really simple one is to just output the times when certain points in your code is hit, output those times into a textfile and then write a simple lua or python script to parse the file and filter the interesting information.

I've used this (or a slightly more complex) version of profiling for most of my hobby-projects and it has proven very helpful.

Answer 3

If you don't want to use gprof, I'm not surprised.

It took me a while to figure out how to do this under GDB, but here's what I do. Get the app running and change focus to the app's output window, even if it's only a DOS-box. Then I hit the Control-Break key (while it's being slow). Then GDB halts and I do info threads and it tells me what threads there are, typically 1 and 2. I switch to the thread I want, like thread 2. Then I do bt to see a stack trace. This tells me exactly what it was doing when I hit Control-Break. I do this a number of times, like 10 or 20, and if there's a performance problem, no matter what it is, it shows up on multiple samples of the stack. The slower it makes the program, the fewer samples I have to take before I see it.

For a complete analysis of how and why it works, see that link.

P.S. I also do handle SIGINT stop print nopass when I start GDB.