windows – 从DLL导出所有内容会影响性能

Does exporting everything from DLL affect performance?

它可能确实如此,但效果是无法估量的.我创建了一个python脚本,用于创建测试DLL导出> 50,000个符号.它由1024个导出的类组成,每个类包含48个函数(16个成员函数,16个虚函数和16个静态函数).编译器还为每个类生成大约4-5个导出,看起来像vtable.

我使用SysInternals ProcMon测量了应用程序的加载时间.在链接DLL之前,非常古老的动力不足的测试机器的加载时间在15-30ms之间.添加DLL,并且对~50,000个导出函数中的每一个进行一次调用都没有产生可测量的变化.

这不是一个完全确定的测试,但足以让我相信符号分辨率和修正可能比任何其他限制因素快一个数量级或更快.

有趣的是,为了能够使用Microsoft工具创建这样一个疯狂的DLL,需要添加/ bigobj编译器标志,并且看起来在DLL的PE格式中也存在64K导出符号的限制.此外,DLL和应用程序的静态(编译时)编译和链接阶段每个花费很多分钟并使用了大量内存.

因此,在遇到装载机性能问题之前,您将推动各种其他限制.

Let’s say I am working with a bunch of legacy DLLs and I noticed they have a lot of unnecessary exports. Will that improve the speed of loading?

不.

Should I go through my DLLs and remove DLLEXPORT on all classes that are not exposed to its clients?

这取决于.

不仅仅是因为负载性能.如果这对应用程序如此重要,那么可能有人会对启动进行基准测试,并确切知道性能问题的确切位置.我们不应该猜测性能影响：

“We should forget about small efficiencies,say about 97% of the time: premature optimization is the root of all evil.” — Knuth

但是,可能还有其他原因导致不导出这些“内部”类和函数.导出类/函数的要点是客户端代码可以使用它.它应该与DLL的逻辑外部API匹配.如果对于函数或类不是这种情况,那么它不应该被导出.如果内部类中有许多功能无法使用或测试,而无需通过DLL的公共API,那么会让人怀疑为什么该功能存在？如果意图是创建通用的可重用类,也许它们应该在自己的库中？

测试驱动设计并不意味着您必须公开展示所有内容.即使是最具侵入性的白盒单元测试,也不一定需要DLL导出.例如,单元测试夹具可以单片构建并静态链接(甚至直接包括源)到任何需要的内部类.

相反,以这种方式完成的完全可原谅的解释可能只是简单易行且易于实现.如果其他一切基本相同(模数式和一些理论架构问题),那么不必要地改变和破坏已经以某种方式完成并且工作正常的系统也是不好的形式.

所以这可能是一个不应该复制或扩展的设计,也许值得在维护或重构机会出现时进行清理.

I think I read somewhere that GCC compiler exports everything by default.

Mingw LD documentation同意.虽然,请注意,如果使用__declspec或.DEF文件导出,则会禁用此自动导出行为.