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.
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.
发布评论
评论（3）
如果您不想使用 gprof，我并不感到惊讶。
我花了一段时间才弄清楚如何在 GDB 下执行此操作，但这就是我所做的。运行应用程序并将焦点更改到应用程序的输出窗口，即使它只是一个 DOS 框。然后我按下 Control-Break 键（虽然速度很慢）。然后 GDB 停止，我执行信息线程，它告诉我有哪些线程，通常是 1 和 2。我切换到我想要的线程，例如线程 2。然后我执行 bt 来查看堆栈跟踪。这准确地告诉我当我按下 Control-Break 键时它正在做什么。我会多次执行此操作，例如 10 或 20 次，如果存在性能问题，无论问题是什么，它都会显示在堆栈的多个样本中。程序运行得越慢，我在看到它之前需要采集的样本就越少。
有关其工作原理和原因的完整分析，请参阅该链接。
PS 当我启动 GDB 时，我也会处理 SIGINT stop print nopass。
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.
gprof 不这样做吗？
我以为 MingW 提供了一个 gprof 版本来配合它。
Does gprof not do it?
I thought MingW provided a gprof version to go with it.
如果你想分析 Lua 脚本，我建议使用 LuaProfiler： http://luaprofiler.luaforge.net /manual.html。它工作得很好。
我强烈建议实现某种计时器或您自己的分析器以获得简单的分析工具。一个非常简单的方法是仅输出代码中某些点被命中的时间，将这些时间输出到文本文件中，然后编写一个简单的 lua 或 python 脚本来解析文件并过滤有趣的信息。
我已经在我的大多数爱好项目中使用了这个（或者稍微复杂一些）版本的分析，并且事实证明它非常有帮助。
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.