问题标签 [memory-footprint]

假设我们有一个编译成 .a 文件的库。之后，该库与其他代码链接到某个可执行文件 .exe 中。.a 文件的大小为 6Mb，而 .exe 文件的大小为 3Mb。对此的明显解释是链接器已从库中抛出未使用的代码。我想知道的是最终可执行文件中真正库的代码足迹。

我有一个包含列、一个小整数、一个整数和两个浮点数的表。每行的预期内存为 14 字节 (2+4+2*4)。我的表中有大约 700,000 行。我没有设置主键和索引。MyIsam 类型占用大约 10MB（每行平均 15b），而 InnoDB 类型占用超过 30Mb（平均 44b）。我在这里想念什么？InnoDB 是否会对每一行产生如此多的开销，或者表状态编号是否不可信。我需要存储将运行到 GB 的数据，因此需要通过权衡不同的参数来决定存储类型。

1. 有什么方法可以测量我的 Java 应用程序中当前使用的永久代 (PermGen) 的大小？我不能使用 VisualVM 等外部分析工具。

2. 更好的是估计 PermGen 中 Java 类的内存消耗。它几乎与字节码文件的大小成正比吗？

我有一个大型的 delphi 应用程序，我试图保持低内存占用。

在我的程序中，我使用了一个组件（Taco）和一个从 taco 继承的组件（TBurrito）。现在只关注类的内存使用而不是实际实例，哪种情况使用更多内存？

A. 在任何地方都只使用 TBurrito 组件

或者

B. 使用 Taco 和 Tburrito 组件的组合？

我的一个想法是，由于 TBurrito 继承了 Taco，所以 Taco 类已经存储在内存中，因此使用它不会增加太多内存占用。

*注意 - 组件名称并不是真正的 Taco 和 Burrito。

以下是关于 K 编程语言的 Wikipedia 条目的摘录：

解释器的小尺寸和语言的紧凑语法使得 K 应用程序可以完全适应处理器的 1 级缓存。

是什么让 K 程序如此之小？当一个人'在 K 中使用运算符时，map在像 Haskell 这样的编译函数语言中，或者在像 C 这样的编译命令式语言中使用等效for循环时，我无法想象编译器会生成完全不同的汇编代码，或者解释器内部发生的事情与for循环有很大不同. K 中是否有什么特别之处使其运行时和程序如此之小？

SO上有一个类似的问题，但那里的答案基本上没有任何澄清。

我想获得总物理内存、CPU 使用率和正在使用的内存量。我已经调查过了Runtime.freeMemory()，但这不是整个系统的可用内存。

Which of the following is better in terms of performance and efficient memory usage?

It should be faster and easier to work with primitive types, but on the other hand, when using a reference to a static object, no new value is created. Or is it optimized on compiler level and all true and false are replaced by references to the static objects to save memory?

我在 Windows 上的 C 应用程序正在运行一个 for 循环，在该循环中它将大量条目转储到某个数据结构中，然后将其保存在 xml 中。现在，我想知道执行相同操作所需的内存占用量。有没有可用的工具？

根据任务管理器，我有一个拥有 130MB 内存的进程，根据dotTrace ，只有 11MB 的实时 .NET 对象，所以我想知道其他 120MB 发生了什么？

我需要一个工具来列出进程中加载​​的程序集和本机 DLL，获取进程中图像的大小，并且对于每个程序集，测量 JITed 方法的内存占用。

来自SysInternal的 ListDlls部分完成了这项工作。但它不测量 JITed 代码大小，它只提供原始数据。理想情况下，我想要一个 UI 来分析和总结这些数据。

最近，Visual Studio 团队报告说使用PerfView工具进行了此类分析。这在博文Visual Studio 11 Beta Performance Part #1部分：The Biggest VM Consumer - DLLs中有说明。有人有使用 PerfView 分析本机 Dll 和程序集足迹的经验和反馈吗？

除了ListDlls和PerfView，你会推荐任何其他工具吗？

好的，Simon Mourier建议的VMMAP似乎是更适合这项任务的工具。VMMAP 显示大部分工作集内存进入托管堆栈（下图中绿色为 113MB），因此问题更多与 .NET 对象相关，而不是非托管内存。绿色锯齿曲线只是装载/卸载会话的时间线。由于某些原因，我的第一个措施是完全错误的：

• dotTrace 告诉我分配了 41MB 的 .NET 对象，
• WMMAP 显示一个 180MB 的工作集（任务管理器显示类似的数字）
• WMMAP 显示由 GC 分配的 113MB 托管堆。此托管堆内存中有 90MB 在工作集中：

所以我的计划是：

1. 确定 GC 为何为 41MB 的 .NET 对象分配 113MB 的托管堆？（这样的数字正常吗？是因为高度碎片化吗？）
2. 努力缩小分配的这组 41MB 的 .NET 对象！

考虑以下 C 程序“pause.c”：

在 x64 Linux 3.0.0-16-generic 上使用这个命令 'gcc -Os pause.c -o pause' 编译它会产生一个大小约为 8KB 的可执行文件。当我运行这个可执行文件并使用“pmap -d PID”检查它的精确内存占用时，它显示分配给进程的私有内存为 192KB（通常在不同的系统之间变化，在 128KB 和 192KB 之间）。

使用 valgrind 和 massif 检查进程未能检测到任何内存分配事件。我怀疑 192KB 的数字是否准确，但我发现启动 5 个“暂​​停”进程实例确实消耗了大约 1MB 的系统内存。

我无法解释这种记忆的起源，任何人都可以提供一些关于为什么分配这种记忆以及任何可能减少它的潜在行动的见解吗？，欢呼。