分析dll/lib bloat

当你建立你的动态链接库时,你可以通过 /MAP 使链接器生成一个映射文件,其中包含结果图像中所有符号的地址。您可能需要执行一些脚本来计算每个符号的大小。

使用A "strings" utility 要扫描DLL,可能会显示意外或未使用的可打印字符串(例如,资源、rcs id, __FILE__ 宏、调试消息、断言等)。

另外,如果您还没有编译 /Os 启用,值得一试。

如果您的最终目标只是缩小dll的大小,那么在调整编译器设置之后,您可能会通过运行dll获得最快的结果。 UPX . upx是一个非常好的用于dll和exes的压缩实用程序;它也是具有非病毒许可证的开源软件,因此可以在商业/封闭源代码产品中使用。

我只让它在最高的压缩设置(蛮力选项)上显示病毒警告,所以如果使用比这更低的设置,您可能会没事的。

虽然我不知道任何二进制大小的配置文件,但您也可以选择查找最大的对象文件(.obj),这至少让您了解问题点在哪里。
当然,这需要一个足够模块化的项目。

您还可以尝试静态链接,而不是使用DLL。实际上,当库静态链接时,链接器会从最终的exe中删除所有未使用的函数。有时,最终的exe只是稍微大一点,您没有更多的dll。

如果您的DLL这么大,因为它导出具有异常长名称的C++函数,另一种方法是使用 .DEF 按顺序导出函数的文件,不带名称(使用 NONAME 在.def文件中)。有点脆弱,但它减少了dll大小、exe大小和加载时间。

参见 http://home.hiwaay.net/~georgech/WhitePapers/Exporting/Exp.htm

假设您使用的是预编译头文件,那么假设所有的.obj文件的大小都差不多,请尝试创建一个空的obj文件,看看它有多大。这将使您了解由于PCH编译而导致的每个.obj的比例。顺便说一下,链接器将能够删除那里的所有副本。或者,您可以尝试禁用PCH,以便obj文件可以更好地指示主要罪犯的位置。

所有好的建议。我要做的就是把地图文件拿出来,然后用眼睛看。我在过去发现的一种情况是,一个或多个类库占用了很大一部分空间,因为某个变量在某个地方被声明为具有一个听起来像可以节省一些编码工作但实际上并不必要的类型。

就像在MFC中一样(还记得吗?)它们有一个包装类来处理win32提供的所有控件、字体等。这些需要很大的空间,而你并不总是需要它们。

另一个可能占用大量空间的是可以在没有集合类的情况下管理的集合类。另一个是不能使用的I/O例程。

我建议您选择以下选项之一:

新闻报道 -你可以运行一个覆盖工具来检测一些死代码

高速缓存 -在客户端缓存初始Activatio上的dll

分裂 -将DLL拆分为几个较小的DLL,使用引导程序DLL启动应用程序,并在应用程序启动后下载其他DLL。

汇编 和链接-使用较小的运行时库,使用大小优化进行编译等。请参见 link 获取更多建议。

压缩 -如果在dll中有数据或大量资源,则只能在下载后或运行时对其进行压缩和解压缩。