Chúng tôi đang nhận được thời gian biên dịch rất chậm, có thể mất hơn 20 phút trên các máy 2 GHz, 2G Ram lõi kép.

Rất nhiều trong số này là do quy mô của giải pháp của chúng tôi đã phát triển tới hơn 70 dự án, cũng như VSS vốn là một cổ chai khi bạn có nhiều tệp. (không may đổi VSS không phải là một lựa chọn không may, vì vậy tôi không muốn điều này rơi vào bash VSS)

Chúng tôi đang xem xét các dự án sáp nhập. Chúng tôi cũng đang xem xét việc có nhiều giải pháp để đạt được sự phân tách mối quan tâm lớn hơn và thời gian biên dịch nhanh hơn cho từng yếu tố của ứng dụng. Điều này tôi có thể thấy sẽ trở thành một địa ngục DLL khi chúng tôi cố gắng giữ mọi thứ đồng bộ.

Tôi muốn biết các nhóm khác đã xử lý vấn đề mở rộng này như thế nào, bạn sẽ làm gì khi cơ sở mã của bạn đạt đến một khối lượng quan trọng mà bạn đang lãng phí nửa ngày để xem thanh trạng thái gửi thông điệp biên dịch.

CẬP NHẬT Tôi bỏ qua đề cập đến đây là một giải pháp C #. Cảm ơn tất cả các đề xuất C ++, nhưng đã được vài năm kể từ khi tôi phải lo lắng về các tiêu đề.

BIÊN TẬP:

Những gợi ý hay đã giúp cho đến nay (không nói rằng không có những gợi ý hay khác bên dưới, chỉ là những gì đã giúp)

• Máy tính xách tay 3GHz mới - sức mạnh của việc sử dụng bị mất hoạt động kỳ diệu khi quản lý
• Vô hiệu hóa Anti Virus trong quá trình biên dịch
• 'Ngắt kết nối' khỏi VSS (thực tế là mạng) trong quá trình biên dịch - Tôi có thể khiến chúng tôi loại bỏ hoàn toàn tích hợp VS-VSS và sử dụng UI VSS

Vẫn không rip-snorting thông qua một biên dịch, nhưng mỗi bit giúp.

Orion đã đề cập trong một bình luận rằng thuốc generic cũng có thể có một vở kịch. Từ các thử nghiệm của tôi, dường như có một hiệu suất tối thiểu, nhưng không đủ cao để chắc chắn - thời gian biên dịch có thể không nhất quán do hoạt động của đĩa. Do giới hạn thời gian, các thử nghiệm của tôi không bao gồm nhiều Generics hoặc nhiều mã như xuất hiện trong hệ thống trực tiếp, do đó có thể tích lũy. Tôi sẽ không tránh sử dụng thuốc generic mà chúng được sử dụng, chỉ để biên dịch hiệu năng thời gian

LÀM VIỆC

Chúng tôi đang thử nghiệm thực tiễn xây dựng các khu vực mới của ứng dụng trong các giải pháp mới, nhập các dll mới nhất theo yêu cầu, họ tích hợp chúng vào giải pháp lớn hơn khi chúng tôi hài lòng với chúng.

Chúng tôi cũng có thể thực hiện chúng giống với mã hiện có bằng cách tạo các giải pháp tạm thời chỉ gói gọn các khu vực chúng tôi cần làm việc và ném chúng đi sau khi tái hòa nhập mã. Chúng ta cần cân nhắc thời gian cần thiết để tái hòa nhập mã này so với thời gian chúng ta đạt được bằng cách không có Rip Van Winkle như các trải nghiệm với việc biên dịch lại nhanh chóng trong quá trình phát triển.

Nhóm Chromium.org đã liệt kê một số tùy chọn để tăng tốc quá trình xây dựng (tại thời điểm này cách trang này một nửa):

Theo thứ tự giảm tốc độ:

• Cài đặt Microsoft hotfix 935225 .
• Cài đặt Microsoft hotfix 947315 .
• Sử dụng bộ xử lý đa lõi thực sự (ví dụ: Intel Core Duo 2, không phải Pentium 4 HT).
• Sử dụng 3 bản dựng song song. Trong Visual Studio 2005, bạn sẽ tìm thấy tùy chọn trong Công cụ> Tùy chọn ...> Dự án và Giải pháp> Xây dựng và Chạy> số lượng bản dựng dự án song song tối đa .
• Vô hiệu hóa phần mềm chống vi-rút của bạn cho các tệp .ilk, .pdb, .cc, .h và chỉ kiểm tra vi-rút khi sửa đổi . Vô hiệu hóa quét thư mục nơi nguồn của bạn cư trú. Đừng làm điều gì ngu ngốc.
• Lưu trữ và xây dựng mã Chromium trên ổ cứng thứ hai. Nó sẽ không thực sự tăng tốc bản dựng nhưng ít nhất máy tính của bạn sẽ phản hồi nhanh khi bạn thực hiện đồng bộ hóa gclient hoặc bản dựng.
• Chống phân mảnh ổ cứng của bạn thường xuyên.
• Vô hiệu hóa bộ nhớ ảo.

Chúng tôi có gần 100 dự án trong một giải pháp và thời gian xây dựng dev chỉ trong vài giây :)

Đối với phát triển địa phương xây dựng, chúng tôi đã tạo ra một Visual Studio Addin rằng những thay đổi Project referencesđể DLL referencesvà trút được các dự án không mong muốn (và một tùy chọn để chuyển đổi chúng trở lại dĩ nhiên).

• Xây dựng toàn bộ giải pháp của chúng tôi một lần
• Dỡ bỏ các dự án mà chúng tôi hiện không làm việc và thay đổi tất cả các tham chiếu dự án thành các tham chiếu DLL.
• Trước khi đăng ký thay đổi tất cả các tham chiếu trở lại từ DLL sang tham chiếu dự án.

Bản dựng của chúng tôi bây giờ chỉ mất vài giây khi chúng tôi chỉ làm việc trên một vài dự án. Chúng ta vẫn có thể gỡ lỗi các dự án bổ sung vì nó liên kết đến các DLL gỡ lỗi. Công cụ này thường mất 10-30 giây để thực hiện một số lượng lớn các thay đổi, nhưng bạn không phải thực hiện thường xuyên.

Cập nhật tháng 5 năm 2015

Thỏa thuận tôi đã thực hiện (trong các bình luận bên dưới), là tôi sẽ phát hành plugin thành Nguồn mở nếu nó đủ quan tâm. 4 năm sau, nó chỉ có 44 phiếu bầu (và Visual Studio hiện có hai phiên bản tiếp theo), vì vậy đây hiện là một dự án ưu tiên thấp.

Tôi đã có một vấn đề tương tự về một giải pháp với 21 dự án và 1/2 triệu LỘC. Sự khác biệt lớn nhất là nhận được ổ cứng nhanh hơn. Từ màn hình hiệu suất 'Trung bình Hàng đợi đĩa 'sẽ nhảy lên đáng kể trên máy tính xách tay cho biết ổ cứng là cổ chai.

Đây là một số dữ liệu cho tổng số lần xây dựng lại ...

1) Máy tính xách tay, Core 2 Duo 2GHz, 5400 RPM Drive (không chắc chắn về bộ nhớ cache. Là Dell Inspiron tiêu chuẩn).

Thời gian xây dựng lại = 112 giây.

2) Máy tính để bàn (vấn đề tiêu chuẩn), Core 2 Duo 2.3Ghz, 7200RPM Drive 8MB Cache.

Thời gian xây dựng lại = 72 giây.

3) Core Core 2 Duo 3Ghz, đơn 10000 RPM WD Raptor

Thời gian xây dựng lại = 39 giây.

Ổ đĩa 10.000 RPM không thể được đánh giá thấp. Xây dựng nơi nhanh hơn đáng kể cộng với mọi thứ khác như hiển thị tài liệu, sử dụng trình duyệt tệp nhanh hơn đáng chú ý. Đó là một sự tăng năng suất lớn bằng cách tăng tốc chu trình xây dựng mã.

Với những gì các công ty chi cho tiền lương của nhà phát triển, thật điên rồ khi họ có thể lãng phí bao nhiêu khi mua trang bị cho họ những chiếc PC giống như nhân viên tiếp tân sử dụng.

Đối với các bản dựng C # .NET, bạn có thể sử dụng .NET Demon . Đây là một sản phẩm tiếp quản quá trình xây dựng Visual Studio để làm cho nó nhanh hơn.

Nó thực hiện điều này bằng cách phân tích những thay đổi bạn đã thực hiện và chỉ xây dựng dự án bạn thực sự thay đổi, cũng như các dự án khác thực sự dựa vào những thay đổi bạn đã thực hiện. Điều đó có nghĩa là nếu bạn chỉ thay đổi mã nội bộ, chỉ có một dự án cần xây dựng.

Tắt phần mềm chống vi-rút của bạn. Nó thêm tuổi cho thời gian biên dịch.

Sử dụng biên dịch phân tán. Xoreax IncrediBuild có thể giảm thời gian biên dịch xuống còn vài phút.

Tôi đã sử dụng nó trên một giải pháp C \ C ++ khổng lồ, thường mất 5-6 giờ để biên dịch. IncrediBuild đã giúp giảm thời gian này xuống còn 15 phút.

Hướng dẫn giảm thời gian biên dịch Visual Studio của bạn xuống một vài giây

Rất tiếc, Visual Studio không đủ thông minh để phân biệt các thay đổi giao diện của một tổ hợp với các thay đổi cơ thể mã không quan trọng. Thực tế này, khi được kết hợp với một giải pháp đan xen lớn, đôi khi có thể tạo ra một cơn bão hoàn hảo của 'bản dựng hoàn chỉnh' không mong muốn gần như mỗi khi bạn thay đổi một dòng mã.

Một chiến lược để khắc phục điều này là vô hiệu hóa các bản dựng cây tham chiếu tự động. Để thực hiện việc này, hãy sử dụng 'Trình quản lý cấu hình' (Trình quản lý cấu hình / xây dựng ... sau đó trong trình đơn thả xuống Cấu hình giải pháp hoạt động, chọn 'Mới') để tạo cấu hình bản dựng mới có tên 'ManualCompile' sao chép từ cấu hình Gỡ lỗi, nhưng thực hiện không chọn hộp kiểm 'Tạo cấu hình dự án mới'. Trong cấu hình xây dựng mới này, bỏ chọn mọi dự án để không ai trong số chúng sẽ tự động xây dựng. Lưu cấu hình này bằng cách nhấn 'Đóng'. Cấu hình bản dựng mới này được thêm vào tệp giải pháp của bạn.

Bạn có thể chuyển từ cấu hình bản dựng này sang cấu hình bản dựng khác thông qua trình đơn thả xuống cấu hình bản dựng ở đầu màn hình IDE của bạn (bản thường hiển thị 'Gỡ lỗi' hoặc 'Phát hành'). Thực tế, cấu hình bản dựng ManualCompile mới này sẽ vô dụng các tùy chọn menu Build cho: 'Build Solution' hoặc 'Rebuild Solution'. Do đó, khi bạn ở chế độ ManualCompile, bạn phải xây dựng thủ công từng dự án mà bạn đang sửa đổi, có thể được thực hiện bằng cách nhấp chuột phải vào từng dự án bị ảnh hưởng trong Solution Explorer, sau đó chọn 'Build' hoặc 'Rebuild'. Bạn sẽ thấy rằng thời gian biên dịch tổng thể của bạn bây giờ sẽ chỉ là vài giây.

Để chiến lược này hoạt động, cần phải có VersionNumber được tìm thấy trong các tệp AssociationInfo và GlobalAss lanhInfo để giữ tĩnh trên máy của nhà phát triển (tất nhiên không phải trong quá trình xây dựng bản phát hành) và bạn không ký vào DLL của mình.

Rủi ro tiềm tàng khi sử dụng chiến lược Hướng dẫn sử dụng này là nhà phát triển có thể quên biên dịch các dự án bắt buộc và khi họ khởi động trình gỡ lỗi, họ nhận được kết quả không mong muốn (không thể đính kèm trình gỡ lỗi, không tìm thấy tệp, v.v.). Để tránh điều này, có lẽ tốt nhất là sử dụng cấu hình bản dựng 'Gỡ lỗi' để biên dịch một nỗ lực mã hóa lớn hơn và chỉ sử dụng cấu hình bản dựng ManualCompile trong quá trình kiểm tra đơn vị hoặc để thực hiện các thay đổi nhanh trong phạm vi giới hạn.

Nếu đây là C hoặc C ++ và bạn không sử dụng các tiêu đề được biên dịch trước, bạn nên làm vậy.

Chúng tôi đã có hơn 80 dự án trong giải pháp chính của chúng tôi, mất khoảng 4 đến 6 phút để xây dựng tùy thuộc vào loại máy mà nhà phát triển đang làm việc. Chúng tôi coi điều đó là quá dài: đối với mỗi bài kiểm tra, nó thực sự ăn mất FTE của bạn.

Vậy làm thế nào để có thời gian xây dựng nhanh hơn? Như bạn có vẻ đã biết, đó là số lượng dự án thực sự gây tổn hại cho thời gian xây dựng. Tất nhiên, chúng tôi không muốn loại bỏ tất cả các dự án của mình và chỉ đơn giản là ném tất cả các tệp nguồn vào một. Nhưng chúng tôi đã có một số dự án mà chúng tôi có thể kết hợp tuy nhiên: Vì mỗi "dự án Kho lưu trữ" trong giải pháp đều có dự án không đáng tin cậy nhất, chúng tôi chỉ đơn giản kết hợp tất cả các dự án nhỏ nhất vào một dự án không đáng tin cậy toàn cầu. Điều đó đã cắt giảm số lượng dự án với khoảng 12 dự án và bằng cách nào đó đã tiết kiệm 40% thời gian để xây dựng toàn bộ giải pháp.

Chúng tôi đang suy nghĩ về một giải pháp khác mặc dù.

Bạn cũng đã thử thiết lập một giải pháp (thứ hai) mới với một dự án mới chưa? Giải pháp thứ hai này chỉ đơn giản là kết hợp tất cả các tệp bằng thư mục giải pháp. Bởi vì bạn có thể ngạc nhiên khi thấy thời gian xây dựng của giải pháp mới đó chỉ với một dự án.

Tuy nhiên, làm việc với hai giải pháp khác nhau sẽ có một số cân nhắc cẩn thận. Các nhà phát triển có thể có xu hướng thực sự làm việc - trong giải pháp thứ hai và hoàn toàn bỏ qua giải pháp đầu tiên. Vì giải pháp đầu tiên với hơn 70 dự án sẽ là giải pháp chăm sóc hệ thống phân cấp đối tượng của bạn, đây sẽ là giải pháp mà máy chủ xây dựng của bạn sẽ chạy tất cả các điểm không mong muốn của bạn. Vì vậy, máy chủ cho Tích hợp liên tục phải là dự án / giải pháp đầu tiên. Bạn phải duy trì hệ thống phân cấp đối tượng của bạn, phải.

Giải pháp thứ hai chỉ với một dự án (sẽ xây dựng nhanh hơn nhiều) sẽ là dự án mà tất cả các nhà phát triển sẽ thử nghiệm và gỡ lỗi. Bạn phải chăm sóc họ nhìn vào máy chủ xây dựng! Nếu bất cứ điều gì phá vỡ nó PHẢI được sửa chữa.

Hãy chắc chắn rằng các tài liệu tham khảo của bạn là tài liệu tham khảo Project, và không trực tiếp đến các DLL trong các thư mục đầu ra của thư viện.

Ngoài ra, có các cài đặt này để không sao chép cục bộ trừ khi thực sự cần thiết (Dự án EXE chính).

Tôi đã đăng phản hồi này ban đầu tại đây: /programming/8440/visual-studio-optimizes#8473 Bạn có thể tìm thấy nhiều gợi ý hữu ích khác trên trang đó.

Nếu bạn đang sử dụng Visual Studio 2008, bạn có thể biên dịch bằng cờ / MP để xây dựng một dự án song song. Tôi đã đọc được rằng đây cũng là một tính năng không có giấy tờ trong Visual Studio 2005, nhưng chưa bao giờ thử bản thân mình.

Bạn có thể xây dựng song song nhiều dự án bằng cách sử dụng cờ / M, nhưng điều này thường được đặt thành số lõi có sẵn trên máy, mặc dù điều này chỉ áp dụng cho VC ++.

Tôi nhận thấy câu hỏi này đã có tuổi, nhưng chủ đề vẫn được quan tâm ngày hôm nay. Gần đây, cùng một vấn đề, và hai điều cải thiện hiệu năng xây dựng nhiều nhất là (1) sử dụng đĩa chuyên dụng (và nhanh) để biên dịch và (2) sử dụng cùng một đầu ra cho tất cả các dự án và đặt CopyLocal thành Sai trên dự án người giới thiệu.

Một số tài nguyên bổ sung:

• /programming/8440/visual-studio-optimizes
• http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx
• http://arnosoftwaredev.blogspot.com/2010/05/how-to-improve-visual-studio-compile.html
• http://blog.brianhartsock.com/2009/12/22/analyzing-visual-studio-build-performance/

Một số công cụ phân tích:

công cụ-> tùy chọn-> Cài đặt dự án VC ++ -> Xây dựng thời gian = Có sẽ cho bạn biết thời gian xây dựng cho mỗi vcproj.

Thêm /Btchuyển đổi vào dòng lệnh trình biên dịch để xem mỗi tệp CPP mất bao nhiêu

Sử dụng /showIncludesđể bắt lồng bao gồm (các tệp tiêu đề bao gồm các tệp tiêu đề khác) và xem các tệp nào có thể tiết kiệm rất nhiều IO bằng cách sử dụng khai báo chuyển tiếp.

Điều này sẽ giúp bạn tối ưu hóa hiệu suất của trình biên dịch bằng cách loại bỏ các phụ thuộc và hiệu suất.

Trước khi chi tiền để đầu tư vào ổ cứng nhanh hơn, hãy thử xây dựng dự án của bạn hoàn toàn trên đĩa RAM (giả sử bạn có RAM để dự phòng). Bạn có thể tìm thấy nhiều trình điều khiển đĩa RAM miễn phí khác nhau trên mạng. Bạn sẽ không tìm thấy bất kỳ ổ đĩa vật lý nào, kể cả SSD, nhanh hơn ổ RAM.

Trong trường hợp của tôi, một dự án mất 5 phút để xây dựng trên i7 6 nhân trên ổ đĩa 7200 RPM với Incredibuild đã giảm chỉ khoảng 15 giây bằng cách sử dụng đĩa RAM. Xem xét nhu cầu lưu trữ để lưu trữ vĩnh viễn và khả năng mất việc, 15 giây không đủ khuyến khích để sử dụng đĩa RAM và có lẽ không có nhiều động lực để chi vài trăm đô la cho ổ đĩa RPM hoặc SSD cao.

Mức tăng nhỏ có thể chỉ ra rằng bản dựng bị ràng buộc CPU hoặc bộ nhớ đệm tệp Windows khá hiệu quả, nhưng vì cả hai thử nghiệm đều được thực hiện từ trạng thái mà các tệp không được lưu trong bộ nhớ cache, tôi nghiêng về các biên dịch gắn với CPU.

Tùy thuộc vào mã thực tế bạn đang biên dịch số dặm của mình có thể khác nhau - vì vậy đừng ngần ngại kiểm tra.

Làm thế nào lớn là thư mục xây dựng của bạn sau khi thực hiện một bản dựng hoàn chỉnh? Nếu bạn gắn bó với thiết lập mặc định thì mọi hội đồng mà bạn xây dựng sẽ sao chép tất cả các DLL của các phụ thuộc của nó và các phụ thuộc của nó, v.v. vào thư mục bin của nó. Trong công việc trước đây của tôi khi làm việc với giải pháp ~ 40 dự án, các đồng nghiệp của tôi đã phát hiện ra rằng cho đến nay, phần đắt nhất của quá trình xây dựng là sao chép các tập hợp này nhiều lần và một bản dựng có thể tạo ra hàng gigabyte bản sao của cùng một DLL và hơn một lần nữa

Dưới đây là một số lời khuyên hữu ích từ Patrick Smacchia, tác giả của NDepend, về những gì ông tin rằng nên và không nên là các hội đồng riêng biệt:

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-ENC-net-assemblies/

Về cơ bản có hai cách bạn có thể giải quyết vấn đề này và cả hai đều có nhược điểm. Một là giảm số lượng lắp ráp, rõ ràng là rất nhiều công việc. Một cách khác là cơ cấu lại các thư mục xây dựng của bạn để tất cả các thư mục bin của bạn được hợp nhất và các dự án không sao chép tệp DLL phụ thuộc của chúng - chúng không cần vì tất cả chúng đều nằm trong cùng một thư mục. Điều này làm giảm đáng kể số lượng tệp được tạo và sao chép trong quá trình xây dựng, nhưng có thể khó thiết lập và có thể khiến bạn gặp một số khó khăn khi chỉ rút ra các DLL được yêu cầu bởi một tệp thực thi cụ thể để đóng gói.

Có lẽ có một số chức năng phổ biến và tạo một số thư viện, theo cách đó, các nguồn tương tự không được biên dịch lặp đi lặp lại cho nhiều dự án.

Nếu bạn lo lắng về các phiên bản DLL khác nhau bị lẫn lộn, hãy sử dụng các thư viện tĩnh.

Tắt tích hợp VSS. Bạn có thể không có lựa chọn sử dụng nó, nhưng DLL bị "vô tình" đổi tên mọi lúc ...

Và chắc chắn kiểm tra cài đặt tiêu đề được biên dịch trước của bạn. Hướng dẫn của Bruce Dawson hơi cũ, nhưng vẫn rất tốt - hãy xem thử: http://www.cygnus-software.com/ con / profompiledheaders.html

Tôi có một dự án có từ 120 exes, libs và dlls trở lên và mất một thời gian đáng kể để xây dựng. Tôi sử dụng một cây các tệp bó gọi các tệp tạo từ một tệp chính. Tôi đã có vấn đề với những điều kỳ lạ từ các tiêu đề gia tăng (hoặc là tính khí thất thường) trong quá khứ vì vậy tôi tránh chúng ngay bây giờ. Tôi thường xuyên thực hiện một bản dựng hoàn chỉnh và thường để nó đến cuối ngày trong khi tôi đi dạo trong một giờ (vì vậy tôi chỉ có thể đoán nó mất khoảng nửa giờ). Vì vậy, tôi hiểu tại sao điều đó là không thể thực hiện được để làm việc và thử nghiệm.

Để làm việc và thử nghiệm, tôi có một bộ tệp bó khác cho mỗi ứng dụng (hoặc mô-đun hoặc thư viện) cũng có tất cả các cài đặt gỡ lỗi - nhưng chúng vẫn gọi cùng một tệp tạo. Thỉnh thoảng tôi có thể tắt DEBUG và cũng quyết định xây dựng hoặc thực hiện hoặc nếu tôi cũng muốn xây dựng các lib mà mô-đun có thể phụ thuộc, v.v.

Tệp bó cũng sao chép kết quả đã hoàn thành vào (hoặc một vài) thư mục kiểm tra. Tùy thuộc vào cài đặt, việc này sẽ hoàn thành trong vài giây đến một phút (trái ngược với nửa giờ).

Tôi đã sử dụng một IDE (Zeus) khác vì tôi muốn có quyền kiểm soát những thứ như tệp .rc và thực sự thích biên dịch từ dòng lệnh, mặc dù tôi đang sử dụng trình biên dịch MS.

Rất vui được gửi một ví dụ về tệp bó này nếu có ai quan tâm.

Vô hiệu hóa lập chỉ mục hệ thống tệp trên các thư mục nguồn của bạn (cụ thể là các thư mục obj nếu bạn muốn nguồn của mình có thể tìm kiếm được)

Nếu đây là một ứng dụng web, đặt cài đặt hàng loạt thành đúng có thể giúp tùy thuộc vào kịch bản.

<compilation defaultLanguage="c#" debug="true" batch="true" >  

Bạn có thể tìm thấy một cái nhìn tổng quan ở đây: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

Bạn cũng có thể muốn kiểm tra các tài liệu tham khảo dự án tròn. Đó là một vấn đề đối với tôi một lần.

Đó là:

Dự án A tham khảo Dự án B

Tham khảo dự án B Dự án C

Tham khảo dự án C Dự án A

Một thay thế rẻ hơn cho Xoreax IB là việc sử dụng những gì tôi gọi là các bản dựng uber-file. Về cơ bản, nó là một tệp .cpp có

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

Sau đó, bạn biên dịch các đơn vị uber thay vì các mô-đun riêng lẻ. Chúng tôi đã thấy thời gian biên dịch từ 10-15 phút xuống còn 1-2 phút. Bạn có thể phải trải nghiệm xem có bao nhiêu #incoles trên mỗi tệp uber có ý nghĩa. Phụ thuộc vào các dự án. vv Có thể bạn bao gồm 10 tập tin, có thể 20.

Bạn phải trả một chi phí vì vậy hãy cẩn thận:

1. Bạn không thể nhấp chuột phải vào tệp và nói "biên dịch ..." vì bạn phải loại trừ các tệp cpp riêng lẻ khỏi bản dựng và chỉ bao gồm các tệp cpp uber
2. Bạn phải cẩn thận với các xung đột biến toàn cục tĩnh.
3. Khi bạn thêm các mô-đun mới, bạn phải cập nhật các tệp uber

Đó là một nỗi đau, nhưng đối với một dự án chủ yếu là tĩnh về các mô-đun mới, nỗi đau nội tâm có thể đáng giá. Tôi đã thấy phương pháp này đánh bại IB trong một số trường hợp.

Nếu đó là một dự án C ++, thì bạn nên sử dụng các tiêu đề được biên dịch trước. Điều này làm cho một sự khác biệt lớn trong thời gian biên dịch. Không chắc chắn những gì cl.exe thực sự đang làm (không sử dụng các tiêu đề được biên dịch trước), có vẻ như nó đang tìm kiếm rất nhiều tiêu đề STL ở tất cả các vị trí sai trước khi cuối cùng đi đến đúng vị trí. Điều này thêm toàn bộ giây cho mỗi tệp .cpp đang được biên dịch. Không chắc chắn nếu đây là một lỗi cl.exe, hoặc một số vấn đề STL trong VS2008.

Nhìn vào cỗ máy mà bạn đang xây dựng, nó có được cấu hình tối ưu không?

Chúng tôi vừa có thời gian xây dựng cho sản phẩm quy mô doanh nghiệp C ++ lớn nhất của chúng tôi giảm từ 19 giờ xuống 16 phút bằng cách đảm bảo trình điều khiển bộ lọc SATA phù hợp đã được cài đặt.

Tế nhị.

Có chuyển đổi MP / MP không có giấy tờ trong Visual Studio 2005, xem http: // nhớsiv.net / blog /? P = 40 , cho phép biên dịch song song trên cơ sở tệp thay vì trên cơ sở dự án. Điều này có thể tăng tốc độ biên dịch dự án cuối cùng, hoặc, nếu bạn biên dịch một dự án.

Khi chọn CPU: Kích thước bộ đệm L1 dường như có tác động rất lớn đến thời gian biên dịch. Ngoài ra, thường có 2 lõi nhanh hơn 4 lõi chậm. Visual Studio không sử dụng các lõi bổ sung rất hiệu quả. (Tôi dựa trên kinh nghiệm của mình với trình biên dịch C ++, nhưng có lẽ nó cũng đúng với trình duyệt C #.)

Bây giờ tôi cũng tin rằng có một vấn đề với VS2008. Tôi đang chạy nó trên máy tính xách tay Intel lõi kép có 3G Ram, đã tắt tính năng chống vi-rút. Việc biên dịch giải pháp thường khá lắt léo, nhưng nếu tôi đã gỡ lỗi thì một lần biên dịch tiếp theo thường sẽ chậm lại khi thu thập dữ liệu. Rõ ràng từ ánh sáng đĩa chính liên tục có một nút cổ chai I / O (bạn cũng có thể nghe thấy nó). Nếu tôi hủy quá trình xây dựng và tắt máy thì hoạt động của đĩa dừng lại. Khởi động lại VS, tải lại giải pháp và sau đó xây dựng lại, và nó nhanh hơn nhiều. Đơn vị lần sau

Tôi nghĩ rằng đây là vấn đề phân trang bộ nhớ - VS vừa hết bộ nhớ và O / S bắt đầu hoán đổi trang để cố gắng tạo khoảng trống nhưng VS yêu cầu nhiều hơn việc hoán đổi trang có thể cung cấp, do đó, nó chậm lại khi thu thập dữ liệu. Tôi không thể nghĩ ra bất kỳ lời giải thích nào khác.

VS chắc chắn không phải là một công cụ RAD, phải không?

Công ty của bạn có tình cờ sử dụng Entrust cho giải pháp PKI / Mã hóa của họ không? Hóa ra, chúng tôi đã có hiệu suất xây dựng rất lớn cho một trang web khá lớn được xây dựng bằng C #, mất hơn 7 phút cho Rebuild-All.

Máy của tôi là i7-3770 với ram 16gb và SSD 512 GB, vì vậy hiệu năng không nên quá tệ. Tôi nhận thấy thời gian xây dựng của tôi nhanh hơn rất nhiều trên một máy thứ cấp cũ hơn đang xây dựng cùng một cơ sở mã. Vì vậy, tôi đã kích hoạt ProcMon trên cả hai máy, lập hồ sơ các bản dựng và so sánh kết quả.

Thật đáng ngạc nhiên, cỗ máy hoạt động chậm có một điểm khác biệt - một tham chiếu đến Entrust.dll trong stacktrace. Sử dụng thông tin mới thu được này, tôi tiếp tục tìm kiếm StackOverflow và thấy điều này: MSBUILD (VS2010) rất chậm trên một số máy . Theo câu trả lời được chấp nhận, vấn đề nằm ở chỗ trình xử lý Entrust đang xử lý kiểm tra chứng chỉ .NET thay vì trình xử lý Microsoft gốc. Tt cũng được đề xuất rằng Entrust v10 giải quyết vấn đề phổ biến này trong Entrust 9.

Tôi hiện đã gỡ cài đặt và thời gian xây dựng của tôi giảm mạnh xuống còn 24 giây . YYMV với số lượng dự án bạn hiện đang xây dựng và có thể không trực tiếp giải quyết vấn đề mở rộng mà bạn đang tìm hiểu. Tôi sẽ đăng một chỉnh sửa cho phản hồi này nếu tôi có thể cung cấp bản sửa lỗi mà không cần dùng đến việc gỡ cài đặt phần mềm.

Chắc chắn là có vấn đề với VS2008. Bởi vì điều duy nhất tôi đã làm là cài đặt VS2008 để nâng cấp dự án đã được tạo bằng VS2005. Tôi chỉ có 2 dự án trong giải pháp của mình. Nó không lớn. Biên dịch với VS2005: 30 giây Biên dịch với VS2008: 5 phút

Những gợi ý hay đã giúp ích cho đến nay (không nói rằng không có những gợi ý hay khác bên dưới, nếu bạn gặp vấn đề, tôi khuyên bạn nên đọc sau đó, chỉ là những gì đã giúp chúng tôi)

• Máy tính xách tay 3GHz mới - sức mạnh của việc sử dụng bị mất hoạt động kỳ diệu khi quản lý
• Vô hiệu hóa Anti Virus trong quá trình biên dịch
• 'Ngắt kết nối' khỏi VSS (thực tế là mạng) trong quá trình biên dịch - Tôi có thể khiến chúng tôi loại bỏ hoàn toàn tích hợp VS-VSS và sử dụng UI VSS

Vẫn không rip-snorting thông qua một biên dịch, nhưng mỗi bit giúp.

Chúng tôi cũng đang thử nghiệm thực tế xây dựng các khu vực mới của ứng dụng trong các giải pháp mới, nhập các dll mới nhất theo yêu cầu, họ tích hợp chúng vào giải pháp lớn hơn khi chúng tôi hài lòng với chúng.

Chúng tôi cũng có thể thực hiện chúng giống với mã hiện có bằng cách tạo các giải pháp tạm thời chỉ gói gọn các khu vực chúng tôi cần làm việc và ném chúng đi sau khi tái hòa nhập mã. Chúng ta cần cân nhắc thời gian cần thiết để tái hòa nhập mã này so với thời gian chúng ta đạt được bằng cách không có Rip Van Winkle như các trải nghiệm với việc biên dịch lại nhanh chóng trong quá trình phát triển.

Orion đã đề cập trong một bình luận rằng thuốc generic cũng có thể có một vở kịch. Từ các thử nghiệm của tôi, dường như có một hiệu suất tối thiểu, nhưng không đủ cao để chắc chắn - thời gian biên dịch có thể không nhất quán do hoạt động của đĩa. Do giới hạn thời gian, các thử nghiệm của tôi không bao gồm nhiều Generics hoặc nhiều mã như xuất hiện trong hệ thống trực tiếp, do đó có thể tích lũy. Tôi sẽ không tránh sử dụng thuốc generic mà chúng được sử dụng, chỉ để biên dịch hiệu năng thời gian