共享对象开销
我们有一个非常模块化的应用程序，其中包含许多共享对象（.so）。有些人认为，在内存/闪存有限的低端平台上，最好将所有内容静态链接到一个大的可执行文件中，因为共享对象会产生开销。
您对此有何看法？
最好的问候，
保罗
We have a very modular application with a lot of shared objects (.so). Some people argue that on low-end platforms with limited memory/flash, it is better to statically link everything into one big executable as shared objects have overhead.
What is your opinion on this ?
Best Regards,
Paul
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
共享库的成本大致为（每个库）：
mmap和mprotect系统调用，以及加载时至少出现一个页面错误。加上与位置无关的代码成本：
如果您有一个大型的长时间运行的应用程序，那么成本对您来说可能根本不重要，除非您使用的是小型嵌入式系统。另一方面，如果您正在编写可能会为短期任务多次调用的东西（例如语言解释器），那么这些成本可能会很大。将所有标准模块放在它们自己的
.so文件中，而不是默认静态链接它们，这是 Perl、Python 等启动如此缓慢的一个重要原因。就我个人而言，我会采用使用动态加载模块作为扩展工具的策略，而不是开发模型。
The costs of shared libraries are roughly (per library):
mmapandmprotectsyscalls, and at least one page fault at load time.Plus position-independent code costs:
If you have a large long-running application, the costs may not matter to you at all, unless you're on a tiny embedded system. On the other hand, if you're writing something that may be invoked many times for short tasks (like a language interpreter) these costs can be huge. Putting all of the standard modules in their own
.sofiles rather than static linking them by default is a huge part of why Perl, Python, etc. are so slow to start.Personally, I would go with the strategy of using dynamic loaded modules as a extensibility tool, not as a development model.
除非内存极其紧张，否则这些文件的一份副本的大小并不是主要决定因素。鉴于这是一个嵌入式系统，您可能很清楚哪些应用程序将使用您的库以及何时使用。如果您的应用程序忠实地打开和关闭它引用的多个库，并且您永远不会同时打开所有库，那么共享库将显着节省 RAM。
您需要考虑的另一个因素是性能损失。打开共享库需要少量（通常是微不足道的）时间；如果您的处理器非常慢或难以满足实时要求，则静态库不会产生共享库的加载损失。进行分析以确定这是否重要。
综上所述，在某些特殊情况下，共享库可以明显优于静态库。在大多数情况下，它们几乎没有造成任何伤害。在简单的情况下，您不会从共享库中获得任何好处。
当然，如果您有多个使用同一库的应用程序（或应用程序的版本），则共享库将在 Flash 中节省大量成本。如果您使用静态库，则每个库都会编译一份副本（与共享库[1]大小大致相同）。当您使用 PC 工作站时，这非常有用。但你知道这一点。您正在使用一个仅由一个应用程序使用的库。
[1] 各个库文件的内存差异很小。共享库添加索引和符号表，以便
dlopen(3)可以加载库。这是否重要取决于您的用例；对每个文件进行编译，然后比较大小以确定 Flash 中哪个较小。您必须运行并分析以确定哪个消耗更多 RAM；除了共享库的初始加载之外，它们应该是相似的。Unless memory is extremely tight, the size of one copy of these files is not the primary determining factor. Given that this is an embedded system, you probably have a good idea of what applications will be using your libraries and when. If your application opens and closes the multiple libraries it references dutifully, and you never have all the libraries open simultaneously, then the shared library will be a significant savings in RAM.
The other factor you need to consider is the performance penalty. Opening a shared library takes a small (usually trivial) amount of time; if you have a very slow processor or hard-to-hit real-time requirements, the static library will not incur the loading penalty of the shared library. Profile to find whether this is significant or not.
To sum up, shared libraries can be significantly better than static libraries in some special cases. In most cases, they do little to no harm. In simple situations, you get no benefit from shared libraries.
Of course, the shared library will be a significant savings in Flash if you have multiple applications (or versions of your application) which use the same library. If you use a static library, one copy (which is about the same size as the shared library[1]) will be compiled into each. This is useful when you're on a PC workstation. But you knew that. You're working with a library which is only used by one application.
[1] The memory difference of the individual library files is small. Shared libraries add an index and symbol table so that
dlopen(3)can load the library. Whether or not this is significant will depend on your use case; compile for each and then compare the sizes to determine which is smaller in Flash. You'll have to run and profile to determine which consumes more RAM; they should be similar except for the initial loading of the shared library.当然，拥有大量库意味着必须存储更多元数据，并且其中一些元数据（库节头等）在加载时需要存储在 RAM 中。但即使在（中等现代的）嵌入式系统上，差异也应该可以忽略不计。
我建议您尝试两种选择，并测量闪存和 RAM 中的已用空间，然后决定哪种方法最好。
Having lots of libraries of course means more meta-data must be stored, and also some of that meta-data (library section headers etc.) will need to be stored in RAM when loaded. But the difference should be pretty negligible, even on (moderately modern) embedded systems.
I suggest you try both alternatives, and measure the used space in both FLASH and RAM, and then decide which is best.