【问题标题】:Estimating memory footprint and CPU usage for a C library估计 C 库的内存占用和 CPU 使用率
【发布时间】:2016-12-16 17:41:18
【问题描述】:

我有一个用 C 编写的静态库,没有动态内存分配。

到目前为止,该库仅用于常规 i386 Linux 的应用程序,其中 CPU 和内存充足。

我现在需要尝试为嵌入式实时 ARM9 系统(由第 3 方提供)构建库版本。在此之前,我必须粗略估计一下内存占用和 CPU 使用率。

对于内存占用,我在 i386 机器上构建了一个小型应用程序,与我的库静态链接,它可以使用我的库的所有功能。检查此应用程序的常驻内存是否可以大致正确地估计我的库的内存占用?有没有更好的测量方法?

为了估计 CPU 使用率,我不知所措。我当然可以在我的 i386 系统上运行上面提到的测试应用程序,但我不知道哪些指标会给我(如果有的话)可以转化为与 ARM 系统相关的东西。有办法吗?

【问题讨论】:

  • 在 RaspberryPi 上编译并运行它,也许可以在上面使用 gprof?
  • Raspberry Pi 使用 ARM11,毫无疑问是不同的系统架构、内存等。如果您发现它在 ARM11 上不好,那么我认为这很有用,但否则您对 ARM9 一无所知。
  • 请澄清您的问题。你说“为了内存占用,我在我的 i386 机器上构建了一个小应用程序......”,但是你是为 i386 还是 ARM9 构建

标签: c cpu-usage static-linking memory-footprint static-allocation


【解决方案1】:

你的内存估计对我来说听起来不错,只要你为 ARM9 编译它。实际上,如果您在没有调试信息的情况下交叉编译库,并且您希望在最终应用程序中使用库的所有功能,那么库的文件大小是一个相当不错的估计值。唯一行不通的方法是如果你有很多零初始化的全局(或静态)变量。当然,运行时内存分配是另一回事,但您已经考虑到了这一点。

基于 x86 代码的大小估计可能在同一个范围内,但实际上不应该被信任。大小也因编译器而异,因此请尽量匹配它,但任何最近的 ARM 编译器都可以粗略估计。

至于 CPU 估算,如果不进行测量,就不可能得出一个数字。它是 CPU 的架构效率、编译器优化的有效性、时钟频率、内存速度、总线速度、缓存大小、其他正在运行的任务造成的缓存压力等等等等的函数。变量太多了。

您可以做的一件事是使用大 O 表示法来说明算法在不同输入上的性能。

我可能只会说“轻”或“重”。您可能知道其中哪个适合。

【讨论】:

  • 你是说在非 ARM 系统上编译库可以合理估计 ARM 系统上的库有多大?这听起来根本不对:使用 2 个不同的编译器为同一架构进行编译会产生 2 个完全不同的内存大小。与 2 种不同的架构相比,情况更糟。
  • 不,我当然不是这么说的。那将是荒谬的。为什么你会想到这个?
  • “对于内存占用,我在 i386 机器上构建了一个小型应用程序”“你的内存估计对我来说听起来不错。”
  • 你说得对,我只是假设他的意思是他交叉编译了它。我会编辑答案。
  • 是的,例如,在 Ubuntu 上安装 QEMU,ARM 二进制文件可以在 x86 上无缝运行。其他发行版可能需要您显式运行 QEMU,无需额外配置。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2014-05-07
  • 2011-09-11
  • 2022-07-26
  • 2015-10-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多