2010-09-01 15 views
5

Trong MSVC, Base Address Randomizaiton là một tùy chọn mặc định (Kể từ VS2005?)ASLR có làm chậm tải Dll không?

Vì vậy, tôi không rebase thủ công địa chỉ cơ sở của dll nữa.

Nhưng tôi đã xóa tất cả các dll của mình để cải thiện hiệu suất tải khi tôi sử dụng VS2003.

Nếu tôi sử dụng tùy chọn ASLR, hiệu suất tải luôn giảm?
(Của cource tôi có thể nhận được các lợi ích khác)

+0

Tôi phải thừa nhận, tôi quan tâm. ASLR dường như đã đảo ngược nhiều thập kỷ hiệu suất cũ từ hệ điều hành. Và tôi biết Windows STILL mất quá nhiều thời gian để khởi động. –

Trả lời

8

Câu trả lời ngắn gọn là không.

Trên một hệ thống mà không ASLR (ví dụ XP), tải một DLL tại một địa chỉ không được ưu tiên có một số chi phí:

  1. Phần di dời đã được phân tích cú pháp và fixups phải được áp dụng cho toàn bộ hình ảnh .
  2. Hành vi áp dụng bản sửa lỗi gây ra lỗi sao chép khi viết tương đối đắt tiền và cũng buộc các trang phải đọc từ đĩa ngay cả khi chúng không được tham chiếu bởi chính ứng dụng.
  3. Mọi quá trình tải tệp DLL tại địa chỉ không ưa thích đều nhận được một bản sao riêng tư của mỗi trang được ghi vào, dẫn đến tăng mức sử dụng bộ nhớ.

Mục 2 và 3 là chi phí lớn nhất và là lý do chính khiến các tệp DLL được sử dụng lại cần thiết.

Với ASLR, bản sửa lỗi được áp dụng một cách minh bạch bởi hệ điều hành, làm cho nó trông giống như DLL thực sự được tải tại địa chỉ ưa thích của nó. Không có lỗi sao chép trên ghi và không có trang quá trình riêng tư nào được tạo. Ngoài ra, bản sửa lỗi chỉ được áp dụng cho các trang thực sự được ứng dụng truy cập chứ không phải toàn bộ hình ảnh, điều đó có nghĩa là không có dữ liệu bổ sung nào được đọc từ đĩa. Ngoài ra, các lược đồ rebasing thủ công không thể ngăn chặn tất cả xung đột địa chỉ cơ sở (ví dụ, DLL từ các nhà cung cấp khác nhau có thể xung đột với nhau hoặc DLL của hệ điều hành có thể tăng kích thước do hotfix và tràn vào một phạm vi dành riêng cho một số DLL khác, v.v.). ASLR hiệu quả hơn trong việc xử lý các vấn đề này, vì vậy khi xem xét toàn bộ hệ thống, ASLR thực sự có thể cải thiện hiệu suất.

+0

Tôi đã viết trình đóng gói/giải nén trước và điểm 1,2,3 của bạn là chính xác khi bạn phải di chuyển bảng di chuyển và áp dụng tất cả các bản sửa lỗi theo cách thủ công vào chương trình lắp ráp. Nhưng tôi nghĩ rằng khi một quá trình nĩa khác, ban đầu họ chia sẻ cùng một trang, cho đến khi cơ chế COW buộc họ phải khác nhau (trong trường hợp ASLR) và do đó sao chép trang là cần thiết. Và điều này cũng có nghĩa là tạo ra các mục TLB bổ sung (đôi khi thậm chí là bộ nhớ đệm của TLB) khi thực hiện dịch trang MMU. Hiệu suất sẽ bị ảnh hưởng vì điều này? –

+5

@Pavel: Bạn đã đến đâu bằng thông tin này? Tôi quan tâm đến việc đọc lên các hiệu ứng hiệu suất của ASLR trên Windows. Khác với câu trả lời của bạn ở đây, tìm kiếm của tôi đã mang lại rất ít. – mcmcc

+0

Tôi chưa bao giờ đọc rằng ASLR "fixups được áp dụng trasnparently bởi hệ điều hành." Có ai có một trích dẫn cho điều đó? –