Kami mendapatkan waktu kompilasi yang sangat lambat, yang bisa memakan waktu lebih dari 20 menit pada mesin dual core 2GHz, 2G Ram.

Banyak dari ini adalah karena ukuran solusi kami yang telah berkembang menjadi 70+ proyek, serta VSS yang merupakan leher botol itu sendiri ketika Anda memiliki banyak file. (menukar VSS bukanlah pilihan, jadi saya tidak ingin ini turun menjadi bash VSS)

Kami melihat penggabungan proyek. Kami juga melihat memiliki beberapa solusi untuk mencapai pemisahan yang lebih besar dari kekhawatiran dan waktu kompilasi yang lebih cepat untuk setiap elemen aplikasi. Ini bisa saya lihat akan menjadi neraka DLL ketika kami mencoba untuk menjaga semuanya tetap selaras.

Saya tertarik untuk mengetahui bagaimana tim lain telah menangani masalah penskalaan ini, apa yang Anda lakukan ketika basis kode Anda mencapai massa kritis yang Anda buang setengah hari menonton bilah status mengirimkan pesan kompilasi.

PEMBARUAN Saya lupa menyebutkan bahwa ini adalah solusi C #. Terima kasih untuk semua saran C ++, tapi sudah beberapa tahun sejak saya harus khawatir tentang header.

EDIT:

Saran bagus yang telah membantu sejauh ini (tidak mengatakan tidak ada saran bagus lain di bawah ini, hanya apa yang telah membantu)

• Laptop 3GHz baru - kekuatan dari utilisasi yang hilang bekerja dengan sangat baik ketika melakukan manajemen
• Nonaktifkan Anti Virus saat dikompilasi
• 'Disconnecting' dari VSS (sebenarnya jaringan) selama kompilasi - Saya mungkin meminta kita untuk menghapus integrasi VS-VSS sekaligus dan tetap menggunakan UI VSS

Masih tidak merobek-robek melalui kompilasi, tetapi setiap bit membantu.

Orion memang menyebutkan dalam komentar bahwa generik mungkin juga bermain. Dari pengujian saya tampaknya ada hit kinerja minimal, tetapi tidak cukup tinggi untuk memastikan - waktu kompilasi dapat tidak konsisten karena aktivitas disk. Karena keterbatasan waktu, pengujian saya tidak menyertakan banyak Generik, atau sebanyak mungkin kode, seperti yang akan muncul dalam sistem langsung, sehingga dapat menumpuk. Saya tidak akan menghindari menggunakan obat generik di mana mereka seharusnya digunakan, hanya untuk kinerja waktu kompilasi

WORKAROUND

Kami menguji praktik membangun area baru aplikasi dalam solusi baru, mengimpor dll dll sesuai kebutuhan, mereka mengintegrasikannya ke dalam solusi yang lebih besar ketika kami senang dengan mereka.

Kami juga dapat melakukan hal yang sama terhadap kode yang ada dengan menciptakan solusi sementara yang hanya merangkum area yang perlu kami kerjakan, dan membuangnya setelah mengintegrasikan kembali kode tersebut. Kita perlu mempertimbangkan waktu yang diperlukan untuk mengintegrasikan kembali kode ini terhadap waktu yang kita peroleh dengan tidak memiliki pengalaman seperti Rip Van Winkle dengan pengompilasi ulang yang cepat selama pengembangan.

Tim Chromium.org mencantumkan beberapa opsi untuk mempercepat pembangunan (pada titik ini sekitar setengah jalan halaman):

Dalam mengurangi urutan speedup:

• Instal perbaikan terbaru Microsoft 935225 .
• Instal perbaikan terbaru Microsoft 947315 .
• Gunakan prosesor multicore sejati (mis. Intel Core Duo 2; bukan Pentium 4 HT).
• Gunakan 3 build paralel. Dalam Visual Studio 2005, Anda akan menemukan opsi di Alat> Opsi ...> Proyek dan Solusi> Bangun dan Jalankan> jumlah maksimum pembangunan proyek paralel .
• Nonaktifkan perangkat lunak anti-virus Anda untuk file .ilk, .pdb, .cc, .h dan hanya periksa virus yang dimodifikasi . Nonaktifkan pemindaian direktori tempat sumber Anda berada. Jangan lakukan hal bodoh.
• Simpan dan bangun kode Chromium di hard drive kedua. Itu tidak akan benar-benar mempercepat build tetapi setidaknya komputer Anda akan tetap responsif ketika Anda melakukan sinkronisasi gclient atau build.
• Defragmentasi hard drive Anda secara teratur.
• Nonaktifkan memori virtual.

Kami memiliki hampir 100 proyek dalam satu solusi dan waktu pengembangan hanya beberapa detik :)

Untuk pembangunan daerah membangun kami menciptakan sebuah Visual Studio Addin bahwa perubahan Project referenceske DLL referencesdan unloads proyek yang tidak diinginkan (dan pilihan untuk beralih mereka kembali tentu saja).

• Bangun seluruh solusi kami satu kali
• Bongkar proyek yang sedang kami kerjakan dan ubah semua referensi proyek menjadi referensi DLL.
• Sebelum check-in, ubah semua referensi kembali dari DLL ke referensi proyek.

Bangunan kami sekarang hanya membutuhkan beberapa detik ketika kami hanya mengerjakan beberapa proyek sekaligus. Kami juga masih bisa men-debug proyek tambahan karena tautannya ke debug DLL. Alat ini biasanya membutuhkan waktu 10-30 detik untuk membuat banyak perubahan, tetapi Anda tidak harus sering melakukannya.

Perbarui Mei 2015

Kesepakatan yang saya buat (dalam komentar di bawah), adalah bahwa saya akan merilis plugin ke Open Source jika cukup diminati. 4 tahun kemudian hanya 44 suara (dan Visual Studio sekarang memiliki dua versi berikutnya), sehingga saat ini merupakan proyek prioritas rendah.

Saya memiliki masalah serupa pada solusi dengan 21 proyek dan 1/2 juta LOC. Perbedaan terbesar adalah semakin cepat hard drive. Dari monitor kinerja 'Rata-rata. Disk Antrian 'akan melompat secara signifikan pada laptop yang menunjukkan hard drive adalah leher botol.

Berikut beberapa data untuk total waktu pembangunan kembali ...

1) Laptop, Core 2 Duo 2GHz, Drive 5400 RPM (tidak yakin tentang cache. Apakah standar Dell inspiron).

Waktu Pembangunan Kembali = 112 detik.

2) Desktop (masalah standar), Core 2 Duo 2.3Ghz, single 7200RPM Drive 8MB Cache.

Waktu Pembangunan Kembali = 72 detik.

3) Desktop Core 2 Duo 3Ghz, single 10.000 RPM WD Raptor

Waktu Rebuild = 39 detik.

Drive 10.000 RPM tidak dapat dikecilkan. Membangun di mana secara signifikan lebih cepat dan segala sesuatu seperti menampilkan dokumentasi, menggunakan file explorer lebih cepat terlihat. Itu adalah peningkatan produktivitas besar dengan mempercepat siklus pengembangan kode.

Mengingat apa yang dibelanjakan perusahaan untuk gaji pengembang, gila berapa banyak mereka dapat memboroskan membeli dengan melengkapi mereka dengan PC yang sama seperti yang digunakan resepsionis.

Untuk C # .NET builds, Anda dapat menggunakan .NET Demon . Ini adalah produk yang mengambil alih proses pembuatan Visual Studio untuk membuatnya lebih cepat.

Ini dilakukan dengan menganalisis perubahan yang Anda buat, dan hanya membangun proyek yang benar-benar Anda ubah, serta proyek lain yang benar-benar mengandalkan perubahan yang Anda buat. Itu berarti jika Anda hanya mengubah kode internal, hanya satu proyek yang perlu dibangun.

Matikan antivirus Anda. Itu menambah usia pada waktu kompilasi.

Gunakan kompilasi terdistribusi. Xoreax IncrediBuild dapat memangkas waktu kompilasi menjadi beberapa menit.

Saya telah menggunakannya pada solusi C \ C ++ besar yang biasanya membutuhkan 5-6 jam untuk dikompilasi. IncrediBuild membantu mengurangi waktu ini menjadi 15 menit.

Petunjuk untuk mengurangi waktu kompilasi Visual Studio Anda menjadi beberapa detik

Visual Studio sayangnya tidak cukup pintar untuk membedakan perubahan antarmuka majelis dari perubahan tubuh kode ngawur. Fakta ini, ketika dikombinasikan dengan solusi besar yang saling terkait, terkadang dapat menciptakan badai sempurna 'bangunan penuh' yang tidak diinginkan hampir setiap kali Anda mengubah satu baris kode.

Strategi untuk mengatasinya adalah dengan menonaktifkan rakitan pohon referensi otomatis. Untuk melakukan ini, gunakan 'Configuration Manager' (Build / Configuration Manager ... lalu di dropdown konfigurasi solusi aktif, pilih 'Baru') untuk membuat konfigurasi build baru yang disebut 'ManualCompile' yang menyalin dari konfigurasi Debug, tetapi lakukan tidak mencentang kotak centang 'Buat konfigurasi proyek baru'. Dalam konfigurasi pembangunan baru ini, hapus centang setiap proyek sehingga tidak ada dari mereka yang membangun secara otomatis. Simpan konfigurasi ini dengan menekan 'Tutup'. Konfigurasi bangunan baru ini ditambahkan ke file solusi Anda.

Anda dapat beralih dari satu konfigurasi build ke konfigurasi build lainnya melalui dropdown konfigurasi build di bagian atas layar IDE Anda (yang biasanya menunjukkan 'Debug' atau 'Release'). Secara efektif konfigurasi build ManualCompile baru ini akan membuat opsi menu Build tidak berguna untuk: 'Build Solution' atau 'Rebuild Solution'. Dengan demikian, ketika Anda berada dalam mode ManualCompile, Anda harus secara manual membangun setiap proyek yang Anda modifikasi, yang dapat dilakukan dengan mengklik kanan pada setiap proyek yang terkena dampak di Solution Explorer, dan kemudian memilih 'Build' atau 'Rebuild'. Anda akan melihat bahwa waktu kompilasi keseluruhan Anda sekarang akan menjadi hanya beberapa detik.

Agar strategi ini dapat berfungsi, diperlukan VersionNumber yang ditemukan di file AssemblyInfo dan GlobalAssemblyInfo agar tetap statis di mesin pengembang (tentu saja tidak selama rilis rilis), dan Anda tidak menandatangani DLL Anda.

Risiko potensial menggunakan strategi ManualCompile ini adalah bahwa pengembang mungkin lupa untuk mengkompilasi proyek yang diperlukan, dan ketika mereka memulai debugger, mereka mendapatkan hasil yang tidak terduga (tidak dapat melampirkan debugger, file tidak ditemukan, dll.). Untuk menghindari hal ini, mungkin lebih baik menggunakan konfigurasi build 'Debug' untuk mengkompilasi upaya pengkodean yang lebih besar, dan hanya menggunakan konfigurasi build ManualCompile selama pengujian unit atau untuk membuat perubahan cepat yang memiliki cakupan terbatas.

Jika ini adalah C atau C ++, dan Anda tidak menggunakan tajuk yang dikompilasi, Anda seharusnya.

Kami memiliki 80+ proyek dalam solusi utama kami yang membutuhkan waktu sekitar 4 hingga 6 menit untuk dibangun tergantung pada jenis mesin yang sedang dikembangkan oleh seorang pengembang. Kami menganggap itu terlalu lama: untuk setiap tes itu benar-benar memakan FTE Anda.

Jadi, bagaimana mendapatkan waktu membangun yang lebih cepat? Seperti yang tampaknya sudah Anda ketahui, itu adalah sejumlah proyek yang benar-benar merusak buildtime. Tentu saja kami tidak ingin menyingkirkan semua proyek kami dan hanya membuang semua sourcefile menjadi satu. Tetapi kami memiliki beberapa proyek yang dapat kami gabungkan: Karena setiap "proyek Repositori" dalam solusi memiliki proyek yang paling tidak mengikat, kami hanya menggabungkan semua proyek yang paling tidak terpecah menjadi satu proyek yang tidak terpasangi global. Itu mengurangi jumlah proyek dengan sekitar 12 proyek dan entah bagaimana menghemat 40% waktu untuk membangun seluruh solusi.

Kami sedang memikirkan solusi lain.

Sudahkah Anda mencoba mengatur solusi baru (kedua) dengan proyek baru? Solusi kedua ini harus dengan sederhana menggabungkan semua file menggunakan folder solusi. Karena Anda mungkin akan terkejut melihat waktu pembuatan solusi baru-dengan-hanya-satu-proyek.

Namun, bekerja dengan dua solusi berbeda akan mengambil beberapa pertimbangan. Pengembang mungkin cenderung benar-benar bekerja di solusi kedua dan benar-benar mengabaikan yang pertama. Karena solusi pertama dengan 70+ proyek akan menjadi solusi yang menangani hierarki objek Anda, ini harus menjadi solusi di mana buildserver Anda harus menjalankan semua unittests Anda. Jadi server untuk Continous Integration harus menjadi proyek / solusi pertama. Anda harus mempertahankan hierarki objek Anda, benar.

Solusi kedua dengan hanya satu proyek (yang akan membangun jauh lebih cepat) akan menjadi proyek di mana pengujian dan debugging akan dilakukan oleh semua pengembang. Anda harus menjaga mereka melihat buildserver sekalipun! Jika ada yang rusak HARUS diperbaiki.

Pastikan referensi Anda adalah referensi Proyek, dan tidak langsung ke DLL di direktori output perpustakaan.

Juga, minta ini untuk tidak menyalin secara lokal kecuali jika benar-benar diperlukan (Proyek master EXE).

Saya memposting respons ini awalnya di sini: /programming/8440/visual-studio-optimizations#8473 Anda dapat menemukan banyak petunjuk bermanfaat lainnya di halaman itu.

Jika Anda menggunakan Visual Studio 2008, Anda dapat mengkompilasi menggunakan flag / MP untuk membangun satu proyek secara paralel. Saya telah membaca bahwa ini juga merupakan fitur tidak berdokumen di Visual Studio 2005, tetapi belum pernah mencoba sendiri.

Anda dapat membangun beberapa proyek secara paralel dengan menggunakan flag / M, tetapi ini biasanya sudah diatur ke jumlah core yang tersedia pada mesin, meskipun ini hanya berlaku untuk VC ++ saya percaya.

Saya perhatikan pertanyaan ini sudah tua, tetapi topiknya masih menarik sampai hari ini. Masalah yang sama menggigit saya belakangan ini, dan dua hal yang paling meningkatkan kinerja build adalah (1) menggunakan disk khusus (dan cepat) untuk mengkompilasi dan (2) menggunakan folder output yang sama untuk semua proyek, dan mengatur CopyLocal ke False pada proyek referensi.

Beberapa sumber tambahan:

• /programming/8440/visual-studio-optimizations
• 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/

Beberapa alat analisis:

tools-> options-> VC ++ pengaturan proyek -> Build Timing = Ya akan memberi tahu Anda waktu pembuatan untuk setiap vcproj.

Tambahkan /Btberalih ke baris perintah kompiler untuk melihat berapa banyak setiap file CPP diambil

Gunakan /showIncludesuntuk menangkap nested include (file header yang menyertakan file header lainnya), dan lihat file apa yang bisa menyimpan banyak IO dengan menggunakan deklarasi maju.

Ini akan membantu Anda mengoptimalkan kinerja kompiler dengan menghilangkan dependensi dan babi kinerja.

Sebelum menghabiskan uang untuk berinvestasi dalam hard drive yang lebih cepat, cobalah membangun proyek Anda sepenuhnya pada disk RAM (dengan anggapan Anda memiliki RAM yang tersisa). Anda dapat menemukan berbagai driver disk RAM gratis di internet. Anda tidak akan menemukan drive fisik apa pun, termasuk SSD, yang lebih cepat daripada disk RAM.

Dalam kasus saya, sebuah proyek yang membutuhkan waktu 5 menit untuk membangun pada i7 6-core pada drive SATA 7200 RPM dengan Incredibuild berkurang hanya sekitar 15 detik dengan menggunakan disk RAM. Mempertimbangkan perlunya menyalin kembali ke penyimpanan permanen dan potensi kehilangan pekerjaan, 15 detik tidak cukup insentif untuk menggunakan disk RAM dan mungkin tidak banyak insentif untuk menghabiskan beberapa ratus dolar pada drive RPM atau SSD yang tinggi.

Keuntungan kecil mungkin menunjukkan bahwa build itu terikat CPU atau bahwa caching file Windows agak efektif, tetapi karena kedua tes dilakukan dari keadaan di mana file tidak di-cache, saya condong ke arah kompilasi terikat-CPU.

Tergantung pada kode aktual yang Anda kompilasi, jarak tempuh Anda mungkin berbeda - jadi jangan ragu untuk menguji.

Seberapa besar direktori build Anda setelah selesai membangun? Jika Anda tetap dengan pengaturan default maka setiap perakitan yang Anda buat akan menyalin semua DLL dari dependensinya dan dependensi dependensi dll ke direktori bin. Dalam pekerjaan saya sebelumnya ketika bekerja dengan solusi ~ 40 proyek, kolega saya menemukan bahwa sejauh ini bagian yang paling mahal dari proses pembuatan adalah menyalin rakitan ini berulang-ulang, dan bahwa satu build dapat menghasilkan gigabyte salinan dari DLL yang sama berulang kali dan lagi.

Berikut ini beberapa saran berguna dari Patrick Smacchia, penulis NDepend, tentang apa yang ia yakini harus dan tidak boleh merupakan majelis terpisah:

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

Pada dasarnya ada dua cara Anda dapat mengatasi hal ini, dan keduanya memiliki kelemahan. Salah satunya adalah mengurangi jumlah majelis, yang jelas banyak pekerjaan. Yang lain adalah merestrukturisasi direktori build Anda sehingga semua folder bin Anda dikonsolidasikan dan proyek tidak menyalin DLL dependensi mereka - mereka tidak perlu karena semuanya sudah ada di direktori yang sama. Ini secara dramatis mengurangi jumlah file yang dibuat dan disalin selama membangun, tetapi bisa sulit untuk diatur dan dapat membuat Anda kesulitan menarik hanya DLL yang diperlukan oleh executable khusus untuk pengemasan.

Mungkin mengambil beberapa fungsi umum dan membuat beberapa perpustakaan, dengan cara itu sumber yang sama tidak dikompilasi berulang-ulang untuk beberapa proyek.

Jika Anda khawatir tentang berbagai versi DLL yang campur aduk, gunakan pustaka statis.

Matikan integrasi VSS. Anda mungkin tidak punya pilihan untuk menggunakannya, tetapi DLL diganti namanya "secara tidak sengaja" sepanjang waktu ...

Dan tentu saja periksa pengaturan tajuk yang sudah dikompilasi. Panduan Bruce Dawson agak lama, tapi masih sangat bagus - lihat: http://www.cygnus-software.com/papers/precompiledheaders.html

Saya memiliki proyek yang memiliki 120 exes atau lebih, lib dan dll dan membutuhkan waktu yang cukup lama untuk dibangun. Saya menggunakan pohon file batch yang memanggil file make dari satu file batch master. Saya memiliki masalah dengan hal-hal aneh dari tajuk inkremental (atau temperamental) di masa lalu jadi saya menghindarinya sekarang. Jarang saya membangun penuh, dan biasanya membiarkannya sampai akhir hari sementara saya berjalan-jalan selama satu jam (jadi saya hanya bisa menebak dibutuhkan sekitar setengah jam). Jadi saya mengerti mengapa itu tidak bisa digunakan untuk bekerja dan menguji.

Untuk bekerja dan menguji saya memiliki satu set file batch untuk setiap aplikasi (atau modul atau perpustakaan) yang juga memiliki semua pengaturan debugging - tetapi ini masih memanggil file make yang sama. Saya dapat menonaktifkan DEBUG dari waktu ke waktu dan juga memutuskan membangun atau membuat atau jika saya juga ingin membangun lib yang bergantung pada modul, dan seterusnya.

File batch juga menyalin hasil yang diselesaikan ke dalam (atau beberapa) folder pengujian. Tergantung dari pengaturan ini selesai dalam beberapa detik hingga satu menit (sebagai lawan mengatakan setengah jam).

Saya menggunakan IDE yang berbeda (Zeus) karena saya ingin memiliki kontrol atas hal-hal seperti file .rc, dan sebenarnya lebih suka mengkompilasi dari baris perintah, meskipun saya menggunakan MS compliers.

Senang memposting contoh file batch ini jika ada yang tertarik.

Nonaktifkan pengindeksan sistem file pada direktori sumber Anda (khususnya direktori obj jika Anda ingin sumber Anda dapat dicari)

Jika ini adalah aplikasi web, pengaturan batch build ke true dapat membantu tergantung pada skenario.

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

Anda dapat menemukan gambaran umum di sini: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

Anda juga mungkin ingin memeriksa referensi proyek melingkar. Itu masalah bagi saya sekali.

Itu adalah:

Referensi Proyek A Proyek B

Referensi Proyek B Proyek C

Referensi Proyek C Proyek A

Salah satu alternatif yang lebih murah untuk Xoreax IB adalah penggunaan apa yang saya sebut build file-uber. Ini pada dasarnya adalah file .cpp yang dimiliki

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

Kemudian Anda mengkompilasi unit uber bukan modul individual. Kami telah melihat waktu kompilasi dari 10-15 menit hingga 1-2 menit. Anda mungkin harus berpengalaman dengan berapa banyak #include per file uber masuk akal. Tergantung pada proyek. dll. Mungkin Anda memasukkan 10 file, mungkin 20.

Anda membayar biaya jadi waspadalah:

1. Anda tidak dapat mengklik kanan file dan mengatakan "kompilasi ..." karena Anda harus mengecualikan masing-masing file cpp dari build dan hanya menyertakan file uber cpp
2. Anda harus berhati-hati terhadap konflik variabel global statis.
3. Saat Anda menambahkan modul baru, Anda harus tetap memperbarui file uber

Agak menyebalkan, tetapi untuk proyek yang sebagian besar statis dalam hal modul baru, rasa sakit awal mungkin sepadan. Saya telah melihat metode ini mengalahkan IB dalam beberapa kasus.

Jika ini adalah proyek C ++, maka Anda harus menggunakan header yang sudah dikompilasi. Ini membuat perbedaan besar dalam waktu kompilasi. Tidak yakin apa yang benar-benar dilakukan cl.exe (dengan tidak menggunakan header yang dikompilasi), tampaknya mencari banyak header STL di semua tempat yang salah sebelum akhirnya pergi ke lokasi yang benar. Ini menambahkan seluruh detik ke setiap file .cpp sedang dikompilasi. Tidak yakin apakah ini adalah bug cl.exe, atau semacam masalah STL di VS2008.

Melihat mesin yang Anda bangun, apakah itu dikonfigurasi secara optimal?

Kami baru saja mendapatkan waktu build kami untuk produk skala enterprise C ++ terbesar kami turun dari 19 jam menjadi 16 menit dengan memastikan driver filter SATA yang tepat telah diinstal.

Halus.

Ada saklar MP / tidak berdokumen di Visual Studio 2005, lihat http://lahsiv.net/blog/?p=40 , yang akan memungkinkan kompilasi paralel berdasarkan file daripada berbasis proyek. Ini dapat mempercepat kompilasi proyek terakhir, atau, jika Anda mengkompilasi satu proyek.

Saat memilih CPU: Ukuran cache L1 tampaknya memiliki dampak besar pada waktu kompilasi. Juga, biasanya lebih baik memiliki 2 core cepat daripada 4 yang lambat. Visual Studio tidak menggunakan core ekstra dengan sangat efektif. (Saya mendasarkan ini pada pengalaman saya dengan kompiler C ++, tetapi mungkin juga berlaku untuk C # one.)

Saya juga sekarang yakin ada masalah dengan VS2008. Saya menjalankannya pada laptop Intel dual core dengan 3G Ram, dengan anti-virus dimatikan. Kompilasi solusinya sering kali cukup licin, tetapi jika saya telah men-debug kompilasi ulang berikutnya akan sering melambat hingga merangkak. Jelas dari lampu disk utama terus menerus bahwa ada bottleneck disk I / O (Anda dapat mendengarnya juga). Jika saya membatalkan build dan shutdown VS aktivitas disk berhenti. Restart VS, muat ulang solusi dan kemudian membangun kembali, dan itu jauh lebih cepat. Unitl lain kali

Pikiranku adalah bahwa ini adalah masalah paging memori - VS kehabisan memori dan O / S mulai bertukar halaman untuk mencoba membuat ruang tetapi VS menuntut lebih dari yang dapat ditukar halaman, sehingga melambat menjadi merangkak. Saya tidak bisa memikirkan penjelasan lain.

VS jelas bukan alat RAD, bukan?

Apakah perusahaan Anda kebetulan menggunakan Entrust untuk solusi PKI / Enkripsi mereka secara kebetulan? Ternyata, kami mengalami kinerja yang sangat buruk untuk situs web yang cukup besar yang dibangun di C #, membutuhkan 7+ menit pada Rebuild-All.

Mesin saya adalah i7-3770 dengan ram 16GB dan SSD 512GB, jadi kinerja seharusnya tidak seburuk itu. Saya perhatikan waktu build saya lebih cepat dari mesin sekunder yang lebih tua yang membangun basis kode yang sama. Jadi saya menyalakan ProcMon di kedua mesin, membuat profil pembuatan, dan membandingkan hasilnya.

Lihatlah, mesin berperforma lambat memiliki satu perbedaan - referensi ke Entrust.dll di stacktrace. Menggunakan info yang baru didapat ini, saya terus mencari StackOverflow dan menemukan ini: MSBUILD (VS2010) sangat lambat pada beberapa mesin . Menurut jawaban yang diterima, masalahnya terletak pada fakta bahwa pengendali Entrust sedang memproses cek sertifikat .NET alih-alih pengendali Microsoft asli. Tt juga menyarankan bahwa Entrust v10 memecahkan masalah ini yang lazim di Entrust 9.

Saat ini saya sudah mencopot pemasangan dan waktu pembuatan saya anjlok hingga 24 detik . YYMV dengan jumlah proyek yang sedang Anda bangun dan mungkin tidak secara langsung mengatasi masalah penskalaan yang Anda tanyakan. Saya akan memposting suntingan ke respons ini jika saya dapat memberikan perbaikan tanpa harus mencopot pemasangan perangkat lunak.

Ini yakin ada masalah dengan VS2008. Karena satu-satunya hal yang saya lakukan adalah menginstal VS2008 untuk meningkatkan proyek saya yang telah dibuat dengan VS2005. Saya hanya punya 2 proyek dalam solusi saya. Itu tidak besar. Kompilasi dengan VS2005: 30 detik Kompilasi dengan VS2008: 5 menit

Saran bagus yang telah membantu sejauh ini (tidak mengatakan tidak ada saran bagus lainnya di bawah, jika Anda mengalami masalah, saya sarankan membaca kemudian, apa yang telah membantu kami)

• Laptop 3GHz baru - kekuatan dari utilisasi yang hilang bekerja dengan sangat baik ketika melakukan manajemen
• Nonaktifkan Anti Virus saat dikompilasi
• 'Disconnecting' dari VSS (sebenarnya jaringan) selama kompilasi - Saya mungkin meminta kita untuk menghapus integrasi VS-VSS sekaligus dan tetap menggunakan UI VSS

Masih tidak merobek-robek melalui kompilasi, tetapi setiap bit membantu.

Kami juga menguji praktik membangun area baru aplikasi dalam solusi baru, mengimpor dll dll sesuai kebutuhan, mereka mengintegrasikannya ke dalam solusi yang lebih besar ketika kami senang dengan mereka.

Kami juga dapat melakukan hal yang sama terhadap kode yang ada dengan menciptakan solusi sementara yang hanya merangkum area yang perlu kami kerjakan, dan membuangnya setelah mengintegrasikan kembali kode tersebut. Kita perlu mempertimbangkan waktu yang diperlukan untuk mengintegrasikan kembali kode ini terhadap waktu yang kita peroleh dengan tidak memiliki pengalaman seperti Rip Van Winkle dengan pengompilasi ulang yang cepat selama pengembangan.

Orion memang menyebutkan dalam komentar bahwa generik mungkin juga bermain. Dari pengujian saya tampaknya ada hit kinerja minimal, tetapi tidak cukup tinggi untuk memastikan - waktu kompilasi dapat tidak konsisten karena aktivitas disk. Karena keterbatasan waktu, pengujian saya tidak menyertakan banyak Generik, atau sebanyak mungkin kode, seperti yang akan muncul dalam sistem langsung, sehingga dapat menumpuk. Saya tidak akan menghindari menggunakan obat generik di mana mereka seharusnya digunakan, hanya untuk kinerja waktu kompilasi