2010-12-14 39 views
10

Ai đó có thể cho tôi lời khuyên để tăng tốc độ xây dựng trong studio trực quan 2008?
Tôi có một dự án lớn với nhiều mô-đun với nguồn đầy đủ. Mỗi lần nó được xây dựng, mỗi tập tin được xây dựng lại, một số trong số chúng không bị thay đổi. Tôi có thể ngăn các tệp này được xây dựng lại không? Tôi quay tài sản "Enable xây dựng lại tối thiểu"/Gm trên nhưng trình biên dịch ném cảnh báo nàyLàm cách nào để tối ưu hóa tốc độ xây dựng trong phòng thu trực quan 2008

Command line warning D9030 : '/Gm' is incompatible with multiprocessing; ignoring /MP switch 

Mỗi mẹo để tăng tốc độ xây dựng sẽ giúp tôi rất nhiều. Cảm ơn,

+0

Bạn đang nói bạn - xây dựng tất cả, thay đổi không có gì và xây dựng lại một lần nữa sẽ biên dịch lại nội dung? –

+0

Xoreax Incredibuild, trong khi không rẻ, giúp ích rất nhiều. Chúng tôi thường xuyên nhận được tăng tốc> 10x.Điều đó nói rằng, phụ thuộc bị hỏng vẫn bị tổn thương rất nhiều bởi vì nó buộc một relink đắt tiền. – MSalters

Trả lời

2

Một cách đơn giản là biên dịch trong chế độ gỡ lỗi (còn gọi là tối ưu hóa 0) chỉ để thử nghiệm nội bộ.

bạn cũng có thể sử dụng các tiêu đề được biên dịch sẵn * để tăng tốc quá trình xử lý hoặc chia nhỏ các phân đoạn 'không thay đổi' thành các lib tĩnh, loại bỏ những phần đó khỏi biên dịch lại.

* với /MP bạn cần để tạo ra các tiêu đề biên dịch sẵn trước khi thực hiện biên soạn đa tiến, như /MP có thể đọc nhưng không viết theo MSDN

+0

Trong trải nghiệm biên dịch của tôi trong chế độ gỡ lỗi chậm hơn nhiều vì việc ghi thông tin gỡ lỗi tạo ra nhiều hoạt động đĩa hơn. – fschmitt

+1

@fschmitt: bạn biết bạn có thể biên dịch trong chế độ gỡ lỗi và không tạo ra thông tin đó, nó gần giống như biên dịch trong bản phát hành không có tối ưu hóa, hoặc cách thực hiện ý nghĩa của tôi, loại bỏ thời gian tối ưu hóa tốn kém và không không làm cho bất kỳ điểm nào khác kém hơn nữa .... – Necrolis

2

Bạn có thể cung cấp thêm thông tin về cấu trúc của dự án và tệp nào đang được xây dựng lại không?
Các tệp C++ không thay đổi có thể được xây dựng lại vì chúng bao gồm các tệp tiêu đề đã được thay đổi, trong trường hợp đó/tùy chọn Gm sẽ không giúp

+0

Dự án của chúng tôi có một số dự án nguồn mở bên ngoài. – tiboo

6

Enable Minimal Build: /Gm không tương thích với Build with Multiple Processes: /MP{<cores>}
Vì vậy bạn chỉ có thể sử dụng một trong của hai loại này tại một thời điểm.

/Gm> Properties dự án: Configuration Properties>C/C++>CodeGeneration
hoặc
/MP {n}> Properties dự án: Configuration Properties>C/C++ >Dòng lệnh


Ngoài ra để ngăn các bản dựng không cần thiết (của các tệp không bị ảnh hưởng) - hãy cấu trúc mã của bạn đúng; Theo quy tắc này:

Trong [.h] file header, đặt chỉ những gì cần thiết bởi nội dung của các tập tin tiêu đề riêng của mình;
và tất cả những gì bạn cần chia sẻ trên nhiều đơn vị thực thi.

Phần còn lại đi trong việc thực hiện [.c/.cpp] file.

+0

OK, nhưng bạn nên chọn cái nào trong số 2? Nếu họ là loại trừ lẫn nhau, làm thế nào đến Microsoft không chỉ đơn giản là giữ tốt nhất? –

2

Tạo lại tất cả các tệp sau khi thay đổi một tệp tiêu đề là một vấn đề phổ biến.Giải pháp là kiểm tra chặt chẽ những gì #include các tập tin tiêu đề của bạn sử dụng và loại bỏ tất cả những gì có thể được gỡ bỏ. Nếu mã của bạn chỉ sử dụng con trỏ và tham chiếu đến một lớp học, bạn có thể thay

#include "foo.h" 

với

class Foo; 
16

C++ biên dịch thời gian được một trận chiến cho mỗi dự án trên một kích thước nhất định. May mắn thay, với rất nhiều người viết các dự án C++ lớn, có nhiều giải pháp khác nhau:

Giải pháp giá rẻ cổ điển là "xây dựng sự thống nhất". Điều này chỉ có nghĩa là sử dụng #include để đặt tất cả các tệp .cpp của bạn vào một tệp duy nhất để biên dịch. "Unity build" đã xuất hiện trong một số câu hỏi ở đây trên stackoverflow, here là câu hỏi nổi bật nhất mà tôi biết. Điều này screencast chứng tỏ làm thế nào để thiết lập một xây dựng như vậy trong Visual Studio.

Sự hiểu biết của tôi là xây dựng sự thống nhất nhanh hơn nhiều so với các bản dựng cổ điển vì bộ nhớ cache hiệu quả công việc được thực hiện bởi bộ tiền xử lý và trình liên kết. Một hạn chế đối với việc xây dựng sự thống nhất là nếu bạn chạm vào một tệp cpp, bạn sẽ phải biên dịch lại tệp cpp "lớn" của mình. Bạn có thể làm việc xung quanh điều này bằng cách phá vỡ tệp cpp mà bạn đang lặp đi lặp lại trong việc xây dựng sự thống nhất và biên dịch nó theo cách riêng của nó.

Ngoài Unity xây dựng, đây là một danh sách các thực hành tốt nhất của tôi:

  • Sử dụng #include chỉ khi cần thiết, thích tờ khai phía trước
  • Sử dụng pimpl thành ngữ để giữ thi lớp ra các tập tin tiêu đề thường được đưa vào. Làm như vậy cho phép bạn thêm thành viên vào một triển khai mà không phải chịu trách nhiệm biên dịch lại
  • Sử dụng các tiêu đề được biên dịch trước (pch) cho các tệp tiêu đề được bao gồm thường hiếm khi thay đổi
  • Đảm bảo rằng hệ thống xây dựng của bạn đang sử dụng tất cả các lõi có sẵn trên phần cứng địa phương
  • Giữ danh sách các thư mục Preprocessor có để tìm kiếm tối thiểu, sử dụng đường dẫn chính xác trong #include báo cáo
  • sử dụng #pragma once ở phía trên cùng của tập tin tiêu đề thay vì #ifndef __FOO_H #define __FOO_H ... #endif, nếu bạn sử dụng các trick #ifndef trình biên dịch sẽ có để mở tệp tiêu đề mỗi khi được bao gồm, #pragma once al làm cho trình biên dịch trở nên hiệu quả hơn

Nếu bạn đang làm tất cả những gì (bản dựng kết hợp sẽ tạo sự khác biệt lớn nhất theo kinh nghiệm của tôi), tùy chọn cuối cùng được phân phối. distcc là giải pháp miễn phí tốt nhất mà tôi biết, incredibuild là tiêu chuẩn ngành độc quyền. Tôi cho rằng tính toán phân tán sẽ là cách duy nhất để có được thời gian lặp lại tuyệt vời trong quá trình biên dịch C++ lộn xộn. Nếu bạn có quyền truy cập vào một số lượng lớn máy móc hợp lý (nói, 10-20), điều này hoàn toàn đáng xem xét. Tôi nên đề cập đến sự hợp nhất xây dựng và phân phối xây dựng không phải là hoàn toàn cộng sinh bởi vì một biên dịch truyền thống có thể được chia thành các phần nhỏ hơn của công việc hơn là một sự thống nhất xây dựng. Nếu bạn muốn phân phối, nó có thể không đáng để thiết lập một bản dựng hợp nhất.

+1

Đối với thứ tự của #pragma một lần và bao gồm bảo vệ, tôi quan sát thấy rằng (1) Microsoft đặt #pragma sau khi bao gồm bảo vệ (2) Ngay cả #pragma đến sau khi bao gồm bảo vệ, trình biên dịch cũng có thể bỏ qua mở tệp. Thử nghiệm của tôi dựa trên VC2010 + SP1, tôi sử dụng/showincludes và procmon để điều tra vấn đề như vậy. – zhaorufei

Các vấn đề liên quan