使用共享库时,为什么在Linux上启动应用程序的速度较慢? [英] Why is the startup of an App on linux slower when using shared libs?

查看:161
本文介绍了使用共享库时,为什么在Linux上启动应用程序的速度较慢?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在我正在使用的嵌入式设备上,启动时间是一个重要问题.整个应用程序由使用一组库的几个可执行文件组成.由于FLASH内存中的空间有限,因此我们想使用共享库.

On the embedded device I'm working on, the startup time is an important issue. The whole application consists of several executables that use a set of libraries. Because space in FLASH memory is limited we'd like to use shared libraries.

在编译并与共享库链接后,该应用程序将照常运行,并且FLASH内存量将按预期减少. 与链接到静态库的版本的不同之处在于,应用程序的启动时间大约要长20秒,而我不知道为什么.

The application workes as usual when compiled and linked with shared libraries and the amount of FLASH memory is reduced as expected. The difference to the version that is linked to static libs is that the startup time of the application is about 20s longer and I have no idea why.

应用程序在带有Linux 2.6.17 OS的180 MHz的ARM9 CPU上运行, 16 MB闪存(JFFS文件系统)和32 MB RAM.

The application runs on an ARM9 CPU at 180 MHz with Linux 2.6.17 OS, 16 MB FLASH (JFFS File System) and 32 MB RAM.

推荐答案

因为共享库必须在运行时链接到通常通过dlopen()或类似方法链接到的库.静态库没有这样的步骤.

Bacause shared libraries have to be linked to at runtime, usually by dlopen() or something similar. There's no such step for static libraries.

更多细节. dlopen必须执行以下任务.

some more detail. dlopen has to perform the following tasks.

  • 找到共享库
  • 将其加载到内存中
  • 递归加载所有依赖项(及其依赖项....​​)
  • 解析所有符号

这需要完成很多IO操作.

This requires quite a lot of IO operations to accomplish.

在静态链接程序中,所有上述所有操作都是在编译时而非运行时完成的.因此,加载静态链接的程序要快得多.

In a statically linked program all of the above is done at compile time, not runtime. Therefore it's much faster to load a statically linked program.

在您的情况下,您的代码必须在相对较慢的硬件上运行,从而扩大了差异.

In your case, the difference is exaggerated by the relatively slow hardware your code has to run on.

这篇关于使用共享库时,为什么在Linux上启动应用程序的速度较慢?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆