ASLR 是否会导致 Dll 加载缓慢？
在MSVC中，基地址随机化是默认选项。（从VS2005开始？）
所以，我不再手动重新设置dll的基地址。
但当我使用 VS2003 时，我重新调整了所有 dll 的基础以提高加载性能。
如果我使用 ASLR 选项，加载性能总是会下降？
（当然我还能得到其他好处）
In MSVC, the Base Address Randomizaiton is a default option.(Since VS2005?)
So, I do not rebase manually the dll's base address anymore.
But I rebased my all dlls to improve loading performance when I use VS2003.
If I use ASLR option, the loading performance is always decreased?
(Of cource I can get other benefits)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
简短的回答是否定的。
在没有 ASLR 的系统（例如 XP）上，在非首选地址加载 DLL 会产生多种成本：
第 2 项和第 3 项是迄今为止最大的成本，也是过去需要手动变基 DLL 的主要原因。
使用 ASLR，操作系统可以透明地应用修复，使 DLL 看起来像是实际加载到其首选地址。不存在写时复制错误，也不会创建进程专用页面。此外，修复仅应用于应用程序实际访问的页面，而不是整个图像，这意味着不会从磁盘读取额外的数据。
除此之外，手动变基方案无法防止所有基址冲突（例如，来自不同供应商的 DLL 可能会相互冲突，或者操作系统 DLL 可能由于修补程序而增加大小并溢出到为保留的范围内）其他一些 DLL 等）。 ASLR 在处理这些问题方面要高效得多，因此从整个系统来看，它实际上可以提高性能。
The short answer is no.
On a system without ASLR (e.g. XP), loading a DLL at a non-preferred address has several costs:
Items 2 and 3 are by far the biggest costs, and are the main reason why manually rebasing DLLs used to be necessary.
With ASLR, fixups are applied transparently by the OS, making it look like the DLL was actually loaded at its preferred address. There are no copy-on-write faults, and no process-private pages are created. Also, fixups are applied only to the pages that are actually accessed by the app, rather than the entire image, which means no extra data is read from disk.
In addition to that, manual rebasing schemes can't prevent all base address conflicts (for example, DLLs from different vendors can conflict with each other, or an OS DLL could increase in size due to a hotfix and spill over into a range reserved for some other DLL, etc.). ASLR is a lot more efficient at dealing with these issues, so when looking at the system as a whole it can actually improve performance.