C 将帮助内联到我的可执行文件中会降低加载/执行速度吗？

我已经编写了一个用C编写的程序，用于命令行使用，预计会经常使用，散布在shell脚本中有专门的帮助，这是

man

或

info

无法提供的，因为它大量使用ANSI转义序列作为颜色

包括转义序列在内的纯文本帮助重18.7kib。内联为以零结尾的字符串的可执行文件（以及根据请求显示它的

if

子句）重39.0 KiB，没有它的可执行文件重19 KiB。（编译时没有优化或调试选项。）

我正在考虑将帮助内联到可执行文件中，以便于用户访问它，而不必记住一个单独的文件名和位置，以便

cat

访问他们的终端。（可执行文件将位于shell搜索路径中，因此这不是问题。）

但我担心加倍会降低加载/执行速度

OTOH我似乎已经读到/听说操作系统将缓存加载的可执行文件，所以我不必对此太担心

另一个选择是制作另一个独立的

-help

可执行文件（它重28kib，但我不需要担心，因为它不经常使用）

---

对于这种情况有什么最佳实践吗？请告知。谢谢大家!

你没什么好担心的

Linux对可执行文件使用请求分页。这意味着当第一次启动可执行文件时，不会从磁盘读取任何内容。只有当页面错误发生时（意味着程序试图访问尚未存在的内存），页面才会从磁盘中实际读取

一些用Go编写的二进制文件大小为数十兆字节，并且没有明显的启动延迟

---

我鼓励您实际尝试每种方法，并对启动延迟进行基准测试。

不要担心这些细节，增加或减少几Kb（甚至Mb）不会产生任何明显的变化。关注你正在使用的算法。对于你正在描述的文本量（几KiB），加载/执行速度的差异将是微不足道的，除非你使用的是一些非常旧/缓慢的硬件。如果您使用的是unix，我不相信这是真的。如果您正在使用这样的硬件，请进行测试以确定其影响是否显著。Jonathan，许多调用和jmp地址都与exe在内存中的加载位置有关。请求分页是如何解决这些问题的？Paul，我不知道你的意思。假设该程序在1000时加载，libfoo在4000时加载。对libfoo的调用仍然可以计算，即使libfoo实际上并不存在于RAM中。从用户空间的角度来看，甚至不存在需求分页；它是透明的。假设一个非请求分页系统和一个（小）可执行文件被加载到内存中。在可执行文件运行之前，是否有加载程序需要修复的地址？如果是这样，按需分页页面会加载到（虚拟）内存中-分页加载程序是否会修复此页面中的地址（它从磁盘上的exe获得）？我现在理解您的问题。你问的是如何/何时应用重新定位。Depmand分页由内核实现，而动态加载则在用户空间中实现。因此，请求分页实际上不会影响加载过程的这一部分。不过，它确实扭转了这个问题：我相信应用重新定位会导致页面在被程序执行/访问之前出错。我相信有一些优化可以避免这种情况。我必须查找引用。当您在Linux上运行动态可执行文件时，内核读取ELF头并看到它正在请求解释器（动态链接器/加载程序，例如

/lib64/ld-Linux-x86-64.so.2

）。内核不加载可执行文件，而是调用加载器（本身必须是静态链接的可执行文件），将要执行的文件的路径传递给加载器

ld.so

然后进入

mmap

将可执行文件的段加载到内存中，然后根据需要执行重新定位。在任何时候，给定的页面是否真的存在于RAM中都取决于内核。