分析嵌入式应用程序
我有一个在嵌入式处理器 (ARM) 上运行的应用程序，我想分析该应用程序以了解它在哪里使用系统资源，如 CPU、内存、IO 等。该应用程序运行在Linux，所以我假设有许多可用的分析应用程序。有人有什么建议吗？
谢谢！
编辑：我还应该补充一点，我们使用的 Linux 版本有点旧（2.6.18）。不幸的是我现在对此没有太多的控制权。
I have an application that runs on an embedded processor (ARM), and I'd like to profile the application to get an idea of where it's using system resources, like CPU, memory, IO, etc. The application is running on top of Linux, so I'm assuming there's a number of profiling applications available. Does anyone have any suggestions?
Thanks!
edit: I should also add the version of Linux we're using is somewhat old (2.6.18). Unfortunately I don't have a lot of control over that right now.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
正如 bobah 所说，gprof 和 valgrind 很有用。您可能还想尝试 OProfile。如果您的应用程序使用 C++（如标签所示），您可能需要考虑禁用异常（如果您的编译器允许）并避免动态强制转换，如 sashang 上面提到的。另请参阅嵌入式 C++。
As bobah said, gprof and valgrind are useful. You might also want to try OProfile. If your application is in C++ (as indicated by the tags), you might want to consider disabling exceptions (if your compiler lets you) and avoiding dynamic casts, as mentioned above by sashang. See also Embedded C++.
如果您的 Linux 不是很有限，那么您可能会找到 gprof 和 valgrind 有用
if your Linux is not very limited then you may find gprof and valgrind useful
与此相关的是，C++ 工作组针对各种 C++ 语言功能的性能成本做了一份技术报告。例如，他们分析了一层或两层动态动态转换的成本。此处的报告 http://www.open-std.org /jtc1/sc22/wg21/docs/TR18015.pdf 它可能会让您深入了解嵌入式应用程序中的痛点可能在哪里。
On a related note, the C++ working group did a technical report on the performance cost of various C++ language features. For example they analyze the cost of dynamic_casting one or 2 levels deep. The reports here http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf and it might give you some insight into where the pain points in your embedded application might be.
gprof可能会让您失望。假设您正在测试的程序大到足以有用，那么调用树很可能会被修剪，因此优化的最佳机会是您可以删除或避免的函数/方法调用。该链接显示了找到它们的好方法。
许多人将其视为测量时间的分层调查过程。
或者你也可以直接在现场抓住它，这就是我所做的。
gprofmay disappoint you.Assuming the program you are testing is big enough to be useful, then chances are the call tree could be pruned, so the best opportunities for optimization are function/method calls that you can remove or avoid. That link shows a good way to find them.
Many people approach this as sort of a hierarchical sleuthing process of measuring times.
Or you can simply catch it in the act, which is what I do.