Tại sao liên kết C++ sử dụng hầu như không có CPU?

Question

Trên dự án C++ gốc, việc liên kết ngay bây giờ có thể mất một hoặc hai phút. Tuy nhiên, trong thời gian này, CPU giảm từ 100% trong quá trình biên dịch xuống gần như bằng không. Điều này có nghĩa là liên kết chủ yếu là một hoạt động đĩa?

Nếu vậy, đây có phải là khu vực chính mà SSD sẽ thực hiện những thay đổi lớn không? Nhưng, tại sao không phải tất cả các tệp OBJ của tôi (hoặc nhiều nhất có thể) được lưu trong RAM sau khi biên dịch để tránh điều này? Với 4   GB RAM Tôi có thể tiết kiệm rất nhiều quyền truy cập đĩa và làm cho CPU bị ràng buộc lại, phải không?

Cập nhật: nên rõ ràng theo dõi là, thể VC++ biên dịch và mối liên kết nói chuyện với nhau tốt hơn để sắp xếp mọi thứ và giữ các tập tin OBJ trong bộ nhớ, tương tự như cách Delphi đúng không?

Answer 1

Khi gỡ lỗi xây dựng trong Visual Studio, bạn có thể sử dụng incremental linking cho phép bạn thường tránh được rất nhiều thời gian cho việc liên kết. Về cơ bản nó có nghĩa là thay vì liên kết toàn bộ tệp EXE (hoặc DLL) từ đầu nó xây dựng dựa trên tệp bạn đã liên kết lần cuối, chỉ thay thế những thứ đã thay đổi.

Tuy nhiên, điều này không được đề xuất cho các bản phát hành vì nó bổ sung thêm một số chi phí trong thời gian chạy và có thể dẫn đến tệp EXE lớn hơn vài lần so với bình thường.

Answer 2

Liên kết thực sự chủ yếu là hoạt động dựa trên đĩa. Borland Pascal (trở lại trong ngày) sẽ giữ toàn bộ chương trình trong bộ nhớ, đó là lý do tại sao nó sẽ liên kết quá nhanh.

Tệp OBJ của bạn không được lưu trong RAM vì trình biên dịch và trình liên kết là các chương trình riêng biệt. Nếu môi trường phát triển của bạn có trình biên dịch và trình liên kết được tích hợp (thay vì chạy chúng như là một quy trình riêng biệt), nó thực sự có thể giữ mọi thứ trong RAM.

Nhưng bạn sẽ mất khả năng tách môi trường phát triển khỏi trình biên dịch và/hoặc trình liên kết - bạn sẽ phải sử dụng trình biên dịch/trình liên kết tương tự và bạn sẽ không thể chạy trình biên dịch bên ngoài môi trường.

Answer 3

Bạn có thể thử cài đặt một số tiện ích đĩa RAM và giữ thư mục obj của bạn trên đĩa RAM hoặc thậm chí toàn bộ thư mục dự án. Điều đó sẽ tăng tốc độ đáng kể.

Đừng quên để làm cho nó vĩnh viễn sau đó :-D

Answer 4

Thật khó để nói chính xác những gì đang diễn mối liên kết lâu như vậy mà không biết làm thế nào nó được tương tác với hệ điều hành. Rất may, Microsoft cung cấp Process Monitor để bạn có thể thực hiện điều đó.

Nó giúp tôi chẩn đoán lỗi với Visual Studio IDE và trình gỡ lỗi mà không cần truy cập nguồn.

Answer 5

Trình liên kết Visual Studio phần lớn được liên kết I/O, nhưng phụ thuộc nhiều vào một vài biến.

1. Liên kết gia tăng (thường gặp trong bản dựng Gỡ lỗi) thường yêu cầu I/O ít hơn nhiều.

2. Viết tệp PDB (đối với biểu tượng) có thể mất nhiều thời gian. Đó là một nút cổ chai cụ thể mà Microsoft nhắm mục tiêu trong VS 2010. Việc viết PDB bây giờ được thực hiện không đồng bộ. Tôi đã không thử nó, nhưng tôi đã nghe nó có thể giúp liên kết thời gian khá một chút.

3. Nếu bạn sử dụng tạo mã thời gian liên kết (LTCG) (phổ biến trong Bản dựng phát hành), ban đầu bạn có tất cả I/O thông thường. Sau đó, trình liên kết sẽ gọi lại trình biên dịch để tạo lại mã cho các phần có thể được tối ưu hóa thêm. Phần này thường có nhiều CPU hơn. Tôi không biết liệu trình liên kết có thực sự quay lên trình biên dịch trong một tiến trình riêng biệt hay không (trong trường hợp này bạn vẫn sẽ thấy mức sử dụng CPU thấp cho quá trình liên kết), hoặc nếu quá trình biên dịch được thực hiện trong quá trình liên kết (trong trường hợp này bạn sẽ thấy trình liên kết đi qua các giai đoạn nặng-I/O sau đó là CPU nặng).

Sử dụng SSD có thể trợ giúp với các phần ràng buộc I/O. Đơn giản chỉ cần có một ổ đĩa thứ hai có thể giúp đỡ, quá. Ví dụ, nếu nguồn và các đối tượng của bạn là tất cả trên một ổ đĩa, và bạn viết PDB của bạn vào một ổ đĩa riêng biệt, trình liên kết nên dành ít thời gian chờ đợi cho các nhà văn PDB. Có một ổ đĩa quay thứ hai đã giúp thời gian liên kết của nhóm hiện tại của tôi đáng kể.