您如何分析您的代码?

发布于 2024-07-04 17:03:05 字数 269 浏览 4 评论 0原文

我希望不是每个人都在使用 Rational Purify。

那么,当您想要测量:

  • 函数
  • 峰值内存使用
  • 代码覆盖率

所花费的时间时,您会做什么?目前,我们手动执行[使用带有时间戳的日志语句和另一个脚本来解析日志并输出到excel。 唷...)

你会推荐什么? 指出工具或任何技术将不胜感激!

编辑:抱歉,我没有首先指定环境,它是专有移动平台上的纯 C

I hope not everyone is using Rational Purify.

So what do you do when you want to measure:

  • time taken by a function
  • peak memory usage
  • code coverage

At the moment, we do it manually [using log statements with timestamps and another script to parse the log and output to excel. phew...)

What would you recommend? Pointing to tools or any techniques would be appreciated!

EDIT: Sorry, I didn't specify the environment first, Its plain C on a proprietary mobile platform

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

歌入人心 2024-07-11 17:03:05

如果你正在做一个“在金属上”嵌入“C”系统(我不太确定你的帖子中的“移动”意味着什么),那么你通常有某种计时器ISR,其中很容易采样发生中断的代码地址(通过在堆栈中挖掘或查看链接寄存器或其他方式)。 然后,以某种粒度/感兴趣范围的组合构建地址直方图就很简单了。

通常,编写一些代码/脚本/Excel 表的组合并不难,这些组合将直方图计数与链接器符号/列表文件中的地址合并起来,为您提供配置文件信息。

如果您的 RAM 非常有限,那么收集足够的数据使其既简单又有用可能会有点麻烦,但您需要告诉我们有关您的平台的更多信息。

If you're doing an 'on the metal' embedded 'C' system (I'm not quite sure what 'mobile' implied in your posting), then you usually have some kind of timer ISR, in which it's fairly easy to sample the code address at which the interrupt occurred (by digging back in the stack or looking at link registers or whatever). Then it's trivial to build a histogram of addresses at some combination of granularity/range-of-interest.

It's usually then not too hard to concoct some combination of code/script/Excel sheets which merges your histogram counts with addresses from your linker symbol/list file to give you profile information.

If you're very RAM limited, it can be a bit of a pain to collect enough data for this to be both simple and useful, but you would need to tell us a more about your platform.

木格 2024-07-11 17:03:05

nProf - 免费,适用于 .NET。

完成工作,至少足以看到 80/20。 (20%的代码,占用80%的时间)

nProf - Free, does that for .NET.

Gets the job done, at least enough to see the 80/20. (20% of the code, taking 80% of the time)

离线来电— 2024-07-11 17:03:05

Windows(.NET 和 Native Exes):AQTime 是一款物超所值的工具。 独立或作为 Visual Studio 插件。

Java:我是 JProfiler 的粉丝。 同样,可以独立运行或作为 Eclipse(或各种其他 IDE)插件运行。

我相信两者都有试用版。

Windows (.NET and Native Exes): AQTime is a great tool for the money. Standalone or as a Visual Studio plugin.

Java: I'm a fan of JProfiler. Again, can run standalone or as an Eclipse (or various other IDEs) plugin.

I believe both have trial versions.

泅人 2024-07-11 17:03:05

Google Perftools 在这方面非常有用。

The Google Perftools are extremely useful in this regard.

浊酒尽余欢 2024-07-11 17:03:05

我在 MSVC 6 和 XP 上使用 devpartner

I use devpartner with MSVC 6 and XP

缱倦旧时光 2024-07-11 17:03:05

对于复杂的应用程序,我非常喜欢英特尔的 Vtune< /a>. 它与检测代码的传统分析器的思维方式略有不同。 它的工作原理是每秒 1,000 次对处理器进行采样以查看指令指针的位置。 它具有不需要对二进制文件进行任何更改的巨大优势,这通常会改变您尝试测量的时间。

不幸的是,它对 .net 或 java 没有好处,因为 Vtune 无法像传统代码那样将指令指针映射到符号。

它还允许您测量各种其他以处理器/硬件为中心的指标,例如每条指令的时钟、缓存命中/未命中、TLB 命中/未命中等,让您确定为什么某些代码部分的运行时间可能比您要长只需检查代码即可期望。

For complex applications I am a great fan of Intel's Vtune. It is a slightly different mindset to a traditional profiler that instruments the code. It works by sampling the processor to see where instruction pointer is 1,000 times a second. It has the huge advantage of not requiring any changes to your binaries, which as often as not would change the timing of what you are trying to measure.

Unfortunately it is no good for .net or java since there isn't a way for the Vtune to map instruction pointer to symbol like there is with traditional code.

It also allows you to measure all sorts of other processor/hardware centric metrics, like clocks per instruction, cache hits/misses, TLB hits/misses, etc which let you identify why certain sections of code may be taking longer to run than you would expect just by inspecting the code.

我只土不豪 2024-07-11 17:03:05

我已经做过很多这样的事了。 如果您有 IDE 或 ICE,有一种技术需要一些手动操作,但不会失败。

警告:现代程序员讨厌这个,我会被否决。 他们喜欢他们的工具。 但它确实有效,而且你并不总是拥有好的工具。

我假设在你的例子中,代码类似于 DSP 或视频,在定时器上运行并且必须很快。 假设您在每个计时器滴答处运行的是子例程 A。编写一些测试代码以在一个简单的循环中运行子例程 A,例如 1000 次,或者足够长的时间让您等待至少几秒钟。

当它运行时,用暂停键随机停止它,并对调用堆栈(不仅仅是程序计数器)进行采样并记录下来。 (这是手动部分。)执行此操作多次,例如 10 次。一次是不够的。

现在寻找堆栈样本之间的共性。 查找至少 2 个样本中出现的任何指令或调用指令。 其中会有很多,但其中一些将在您可以优化的代码中。

这样做,保证你会得到很好的加速。 1000 次迭代将花费更少的时间。

您不需要大量样品的原因是您不是在寻找小东西。 就像如果您在 10 个样本中的 5 个上看到特定的调用指令,则它大约占总执行时间的 50%。 如果您确实想知道的话,更多样本可以更准确地告诉您百分比是多少。 如果您像我一样,您只想知道它在哪里,这样您就可以修复它,然后继续进行下一个。

这样做,直到您找不到更多可以优化的东西,并且您将达到或接近最高速度。

I've done this a lot. If you have an IDE, or an ICE, there is a technique that takes some manual effort, but works without fail.

Warning: modern programmers hate this, and I'm going to get downvoted. They love their tools. But it really works, and you don't always have the nice tools.

I assume in your case the code is something like DSP or video that runs on a timer and has to be fast. Suppose what you run on each timer tick is subroutine A. Write some test code to run subroutine A in a simple loop, say 1000 times, or long enough to make you wait at least several seconds.

While it's running, randomly halt it with a pause key and sample the call stack (not just the program counter) and record it. (That's the manual part.) Do this some number of times, like 10. Once is not enough.

Now look for commonalities between the stack samples. Look for any instruction or call instruction that appears on at least 2 samples. There will be many of these, but some of them will be in code that you could optimize.

Do so, and you will get a nice speedup, guaranteed. The 1000 iterations will take less time.

The reason you don't need a lot of samples is you're not looking for small things. Like if you see a particular call instruction on 5 out of 10 samples, it is responsible for roughly 50% of the total execution time. More samples would tell you more precisely what the percentage is, if you really want to know. If you're like me, all you want to know is where it is, so you can fix it, and move on to the next one.

Do this until you can't find anything more to optimize, and you will be at or near your top speed.

单身情人 2024-07-11 17:03:05

您可能需要不同的工具来进行性能分析和代码覆盖率。

对于分析,我更喜欢 MacOSX 上的 Shark。 它是苹果免费的,而且非常好。 如果您的应用程序是 vanilla C,那么您应该能够使用它,前提是您有一台 Mac。

对于 Windows 上的分析,您可以使用 LTProf。 便宜,但不是很好:
http://successfulsoftware.net/2007/12/18/optimising-your -application/

(我认为微软没有为更便宜的 Visual Studio 版本提供像样的分析器,这确实是搬起石头砸自己的脚。)

对于覆盖率,我更喜欢 Windows 上的覆盖率验证器:
http://successfulsoftware.net/2008/03/10/coverage-validator/< /a>
它实时更新覆盖范围。

You probably want different tools for performance profiling and code coverage.

For profiling I prefer Shark on MacOSX. It is free from Apple and very good. If your app is vanilla C you should be able to use it, if you can get hold of a Mac.

For profiling on Windows you can use LTProf. Cheap, but not great:
http://successfulsoftware.net/2007/12/18/optimising-your-application/

(I think Microsoft are really shooting themself in the foot by not providing a decent profiler with the cheaper versions of Visual Studio.)

For coverage I prefer Coverage Validator on Windows:
http://successfulsoftware.net/2008/03/10/coverage-validator/
It updates the coverage in real time.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文