Yavaş bir derleme ortamında kodlama için en iyi yaklaşım nedir

15

C # 'da TDD tarzında kodlama yapıyordum - küçük bir kod parçası yazdım / değiştirdim, tüm çözümü 10 saniye içinde yeniden derledim, testleri tekrar çalıştırdım. Kolay...

Bu geliştirme metodolojisi, C ++ kodlamasına geri dönmem gereken bir yıla kadar birkaç yıl boyunca benim için çok iyi çalıştı ve üretkenliğimin o zamandan beri önemli ölçüde azaldığını hissediyor. Bir dil olarak C ++ bir sorun değil - C ++ dev deneyimi için oldukça fazla şey vardı ... ama geçmişte.

Küçük projeler için verimliliğim hala iyi, ancak proje boyutunun artmasıyla daha da kötüleşiyor ve derleme süresi 10+ dakikaya ulaştığında gerçekten kötüleşiyor. Ve ben hata bulursam tekrar derleme, vb başlatmak gerekir. Bu sadece tamamen sinir bozucu.

Böylece küçük bir parçada (daha önce olduğu gibi) kabul edilemez olduğu sonucuna vardım - herhangi bir öneri kodları elle incelerken (hızlı bir C # derleyicisine güvenmeden) kendimi bir saat kadar eski kodlama alışkanlığına nasıl sokabilirim ve birim testlerini yalnızca birkaç saatte bir yeniden derleme / yeniden çalıştırma.

Bir C # ve TDD ile evrimsel bir şekilde bir kod yazmak çok kolaydı - bir düzinelerce yinelemeden sonra hangi boktan başladığım iyi bir kodla bitiyordu, ama artık benim için çalışmıyor (yavaş bir derlemede) ortam).

c++ productivity development-environment

— tatarcık
kaynak

stackoverflow.com/questions/5078409/… Bunlar muhtemelen birleştirilmeli / tek bir yerde olmalıdır.

— Ben L

C ++ derleme sürelerini hızlandırmak için laso stackoverflow.com/questions/373142/… adresine bakın .

— Tutulma

2

Bir kılıç dövüşü başlat . ; p

— Steven Jeuris

C ++ 'ı son derlemede, önceden derlenmiş üstbilgileri kullanarak derleme süresini dört faktör oranında kesti.

— gnasher729

16

Aklıma birkaç şey geliyor:

Dağıtılmış derlemeyi kullanın . Bunu GCC ("distCC"?) Veya VC ( Xoreax 'IncrediBuild ile tam olarak ucuz değil, harcanan her kuruşa değer.) İle yapabilirsiniz.
Projenizi dinamik olarak yüklenen kitaplıklara ayırın ve onlara bağımlılıkları en aza indirmeye çalışın. Daha küçük yürütülebilir dosyalar daha hızlı bağlantı kurar.
Büyük uygulama yerine küçük test projelerine karşı program yapın .
Derleme zamanında algoritmalar gerçekleştirmek için şablon-meta programlama kullanın . Evet, bu aslında derleme sürelerini artıracak, ancak test için gereken geri dönüşleri de azaltacaktır: İyi derlenirse, yapılır.
Donanıma yatırım yapın . Daha fazla CPU çekirdeği (makinenizde veya diğerlerinde) dağıtılmış derlemeyi merak edecektir ve çok fazla bellek artı hızlı bir disk (HDD yerine SSD) çok yardımcı olacaktır. 64 bit sisteminiz ve müstehcen miktarlarda RAM'iniz varsa, bir RAM diskinde derlemek inanılmaz bir hız artışı sağlayabilir.

— sbı
kaynak

1

derleyici önbellekler aslında benim deneyim dağıtık derleme daha iyi bir fikir.

— pqnet

RAM diskine SSD'den bahsetmişken, derleme hızında çok fazla artış sağlamadığına oldukça şaşırdım. Mevcut projem (Android'de Java) SSD'den ~ 45 saniyede ve RAM diskinden ~ 40 saniyede temiz durumdan derleniyor (ve tüm araç zinciri sadece kaynaklarda değil, RAM diskinde). Dramatik bir artış değil.

— Haspemulator

10

Henüz başkaları tarafından belirtilmeyen bir diğer teknik çözüm, normal sabit sürücüler yerine Katı Hal Sürücülerine geçmek. Üzerinde çalıştığım bir önceki projede, SSD'ler 30 dakikadan 3 dakikaya kadar inşa sürelerini düşürdü.

Tabii ki pahalıdırlar. Patronunuz için, kaybedilen geliştirici zamanının fiyatını bir defalık yatırımın fiyatına göre hesaplayın. Yatırım muhtemelen birkaç ay içinde kendini amorti eder.

— Péter Török
kaynak

6

İlginç. Bu, derleme süresinin% 90'ının G / Ç disk gecikmesi olduğunu söylüyor.

— Mike Dunlavey

% 90'lık bir düşüş görmedim, ancak önemli bir düşüş gördüm. Derlemeyi hızlandırmıyor gibi görünüyor, ancak bağlantıyı kesinlikle hızlandırıyor. Büyük bir projede küçük değişiklikler yapıyorsanız (yani bir değişiklikte çok fazla derleme olmaz) ve yeniden bağlanıyorsa, bunu elde edebilirsiniz. (Bu Visual Studio 2008, C ++ kullanıyor.)

— David Thornley

1

Bu iyi bir fikir. Ayrıca, RAM'in bir kısmını dosya sisteminize monte etmek hızlı çalışır ve ucuzdur.

— Goran Jovic

2

Ramdisk daha hızlı (ve daha ucuz).

— SK-logic

1

@John: Evet, iyi yazılmış bir derleyici (IMHO) G / Ç bağlı olmalıdır.

— Mike Dunlavey

3

Daha fazla planlama, daha büyük parçalar halinde kodlama, birim testleri yerine entegrasyon testleri yazma ve build + test paketini gece boyunca çalıştırma.

— Nemanja Trifunovic
kaynak

3

Uzun derleme süreleri bazen bir problemdir, ancak daha önce bahsedilen modülerleşme bunun (çoğunlukla) üstesinden gelmeye yardımcı olabilir.

Hiç bir şekilde derleyemeyeceğiniz bir ortamda, her kod değişikliğinin test / geliştirme ortamına başvurmak için başka bir kıtadaki başka bir bölüme sunulması gereken, tamamlanması günler alabilen bir süreçte çok daha ciddi sıkışıyor.

Şimdi böyle bir ortamda çalışıyorum ve bu sistem zaten bir hafta boyunca bana mal oldu (ve proje sadece para bitmeden önce toplam 4 hafta bütçeye sahip) sadece değişikliklerin ilk sürümünü yüklemek için (ve daha sonra dosyaların bir kısmının uygulama sunucusu tarafından alınmamasına neden olan hatalar yaptılar, bu yüzden birkaç gün daha gecikmelere bakıyoruz). Şimdi yapılan her küçük değişiklik (testte, kaçırılan bir hata durumu gibi düzeltilmesi gereken bir şey bulduğumuzu düşünün) başka bir gün veya daha fazla gecikmeye neden olabilir.

Bu gibi durumlarda, kodunuzu derlemeye bile başlamadan önce hiçbir hata olmadığından emin olun. Neredeyse tüm derleme ve test çalışmaları için ayda 5 dakika CPU zamanımızın olduğu ana bilgisayar programlamasına geri döndüğümüzü hissettiriyor.

— jwenting
kaynak

1

Evlat, bu cehennemden gelen bir durum. Ana bilgisayar günlerini hatırlıyorum. Bir sürü "Danışma denetimi" kodunu yaptım. Ay'a yapılan uçuşların sonsuz simülasyonları gibi, bu şekilde ne kadar yapıldığı şaşırtıcı.

— Mike Dunlavey

3

Yapıların ne zaman uzun sürdüğünü kolayca hatırlıyorum. Bazı hafifletici yaklaşımlar:

Kitaplıkları veya dll'leri birleştirerek sistemi oluşturun. Bu şekilde, bazı kodları değiştirdiğinizde, yeniden derlenmesi gereken tek parça sizin parçanızdır.
Bir özelliği uygulamak için kodda düzenlemeniz gereken nokta sayısı, yalnızca ne kadar düzenleme yapmanız gerektiğini değil, hata koyma sıklığınızı da etkiler, derleme-hata ayıklama-düzenleme-derleme döngüsünü yükseltir. DRY gibi kodun yedekliliğini azaltan her şey yardımcı olur.
Hata ayıklayıcıdaysanız ve hata ayıklayıcıdan ayrılmadan düzenleyebilir, yeniden derleyebilir ve devam edebilirsiniz, bu gerçekten yararlıdır.

— Mike Dunlavey
kaynak

2

Derleme için 10 dakikadan fazla mı? Ciddi anlamda?

Artımlı bina yapan bir IDE mi kullanıyorsunuz (örneğin Eclipse)? Değilse, muhtemelen olmalı, temel derlemeyi dakikalar yerine saniyeler içinde yapacaktır.

Yoksa değişikliğinizi test etmek için tüm uygulamayı oluşturmanız gereken entegrasyon konularından mı bahsediyorsunuz? Öyleyse, tüm yapıyı yapmadan önce büyük hataların kodunuz dışında olduğundan emin olmak için daha küçük testlere bakın.

— TrueDub
kaynak

5

10mins küçük. Tek çekirdekli bir makinede, PCH'lerde ve hepsinde sıfırdan derleme ve bağlantı kurma bir saat süren bir proje için çalıştım. Tabii ki, otomatik sürüm yapıları dışında kimse onu sadece bir işlemci çekirdeği üzerine inşa etmeyecekti, ama yine de ... Hemen her yerde bulunan bir başlıktaki bir şeyi değiştirmek zorunda olsaydınız (dize manipülasyonu, hata işleme), çıldırmış olabilirsiniz.

— sbi

2

Tam bir yapı için derlenmesi 48 saat süren bir sistemde (yıllar önce) çalışırdı. Tabii ki tam bir inşaat sadece Cuma akşamı başladı, umarım pazartesi günü ofise döndüğümüzde yapılacaktır. Bunun yerine, gerektiğinde küçük modüller oluşturduk (tek bir DLL diyelim).

— jwenting

2

TrueDub + 1 + olabilir yukarıdaki tüm yorumları -1. Evet, her şeyi yeniden derliyorsanız, çok uzun zaman alabilir. Bununla birlikte, bağımlılık yönetimine herhangi bir düşünce verilirse, 10 saatlik tüm yeniden derleme projeleri norm olarak bir dakikadan kısa bir sürede artımlı yeniden derlemelere sahip olabilir. Hepiniz kendinizden utanmalısın, işverenlerinizin biraz zeka uygularken yeniden derlemelerinizi beklerken zaman kaybetmesi çok zaman kazandıracak.

— Dunk

2

Ve birkaç MLoC projesinde oturan küçük bir dükkanda çalışıyorsanız, kodun önemli bir bölümünün eski olduğu, on yıl önce derleme hızının hiçbir zaman bir sorun olmadığı birden fazla küçük proje olarak başladığı anlamına gelir, ve bağımlılık yönetimi çok kötü. Peki böyle bir şirkete tüm bunları atmasını ve on yıl daha yazmak için harcayacağını mı söyleyeceksiniz?

— sbi

2

@Dunk: Bir düzineden fazla geliştiricinin multi-MLoC projesinde çalıştığı küçük bir şirketti. Bu , yüzlerce geliştiricinin bunu yapmasından çok farklı: sıfırdan hiçbir şeyi yeniden yazamazsınız , çünkü bunu yapmak için yıllara ihtiyacınız olacak. Bu fikirden nefret ettiğim kadar, dağıtılmış derlemeye yatırım yapmak ekonomik olarak mümkün oldu, yeniden yazma değildi. Oh, ve ben bu arayüzleri miras aldım. :-xOn yıl önce orada düşünülmemiştim. (Bu kodun çoğunu TMP kullanmak, derlemede daha fazla hata bulmak ve sahada daha az bulmak için değiştirdim.)

— sbi

2

Birincisi, ilk etapta derlemek neden bu kadar uzun sürüyor?

Ortamınız (IDE, marka, ne olursa olsun) artımlı yapıları destekliyor mu? Her şeyi değil, yalnızca değişiklikleri yeniden derlediğinizden emin olun.
Çok çekirdekli bir makineniz varsa, IDE'niz paralel derlemeyi destekleyebilir. Visual Studio'nun bunu yaptığını biliyorum. Görünüşe göre gcc de öyle. Bu yüzden daha iyi bir makine edinin ve paralel derlemeyi etkinleştirin.
Önceden derlenmiş başlıklar kullanmayı düşünün.
Tüm bunları denerseniz ve derleme hala yavaşsa, kodunuzu gözden geçirin. Gereksiz bağımlılıkları arayın. Ön bildirimin yeterli olacağı bir başlık ekliyor musunuz? Üstbilgilere bağımlılığı azaltmak için PIMPL deyimini kullanmayı düşünün.

Tüm bunlardan sonra oluşturma süreniz hala yavaşsa, sorunu çözün: birçok küçük test projesi oluşturun ve her biri üzerinde ayrı ayrı çalışın. Yeni bir ödeme yapan, her şeyi oluşturan ve tüm birim testlerini otomatik olarak yürüten otomatik bir gece oluşturma sisteminiz olduğundan emin olun.

Son olarak, değişikliklerinizi test etmeniz hala uzun zaman alıyorsa, daha fazla düşünün. Sürüm kontrol sisteminizde bir fark yaptığınızdan ve test etmeden önce tüm değişiklikleri dikkatle gözden geçirdiğinizden emin olun. Kısacası, bu, bir test için geri dönüş süresinin uzun olduğu ve sistemin durumunu inceleme yeteneğinizin sınırlı olduğu gömülü sistem geliştirme gibidir.

Bu beni başka bir düşünceye götürüyor: günlüğü kullanmak için kodunuzu kullanın. Bu şekilde, bir düzine kez yeniden oluşturmadan ve yeniden çalıştırmadan sorunun ne olduğunu görebilirsiniz.

— Dima
kaynak

2

GCC'nin paralel derlemeleri destekleyip desteklemediğinden emin olursunuz, eğer bunu yaparsanız marka veya benzer araçların GCC'nin birkaç kopyasını başlatacağı gerçeği.

— Zachary K

1

PIMPL için +1. Yapım sürelerinin kontrolden çıktığı bir proje üzerinde çalıştım. Bu projede, her bir başlığa başka kaç başlık eklendiğine dikkat etmedim. Bir sonraki projemde, PIMPL'den kapsamlı olarak yararlanarak bunu en aza indirmeyi düşündüm. İkinci proje muhtemelen ilk projenin iki katı büyüklüğünde olsa da, derleme süreleri büyük olmaya devam ediyor.

— Jason B

1

Muhtemelen çok uçlu bir yaklaşıma ihtiyacınız vardır:

1) Daha hızlı inşa sistemleri. Ödeyebileceğiniz kadar çok çekirdek / ram / hızlı disk. Daha büyük C ++ projeleri için diskin genellikle bir sınırlayıcı olduğunu görürsünüz, bu yüzden hızlı olanlara sahip olduğunuzdan emin olun.

2) Projenin daha modülerleştirilmesi. Değişiklikleri her şeyin tam olarak yeniden derlemesine neden olamayacak şekilde şeyleri ayırın. Açıkçası, projenin bir kısmı tamamen diğerlerinden boşanabilir böylece ayrı dll / so dosyaları içine mümkün olduğunca çok temel şeyler itin.

3) Ortamınıza uygun olarak artımlı derlemeler / dağıtılmış derlemeler / önbellekleme. Bazı sistemlerde, distcc (dağıtılmış bina) ve ccache (kısmen inşa edilmiş öğelerin önbelleğe alınması) çok fazla derleme süresi kazandırabilir.

4) Yapınızın iyi paralelleştirilebildiğinden emin olun. Özellikle kalıcı bir ortamda, Makefiles'i yanlışlıkla paralel bina yapamayacağınız şekilde ayarladığınız bir duruma girmek zor değildir.

— Michael Kohne
kaynak

0

Kapsamlı günlük kaydı ve dahili doğrulama, uzun geri dönüş süreleri için yardımcı olmuştur. Derlemeniz bittiğinde, tek bir işlem aynı anda çok sayıda olası sorunu ortaya çıkarabilir.

Oldukça karmaşık algoritmalar veya defter tutma ile uğraşırken, 'gerçek' olana paralel olarak oldukça basitleştirilmiş bir sürüm eklemek yararlı olabilir. Herhangi bir çalışmada, kullanışlı referans verileriniz vardır.

— Joris Geer
kaynak

0

@ Ve Michael Kohne ne dedi.

Yapım sürecinin kendisine zaman ve enerji harcayın. Bir zamanlar tam bir yapı için bir saatten fazla süren görkemli, olgun bir ürünümüz vardı. Yapı bağımlılıklarının iddia ettiklerini tespit etmek için çok zaman ve enerji harcandı ve daha sonra gerçekte olduklarını düzeltmek / azaltmak. İnşa süresi ~ 30 dakikaya düştü.

Yapım araçlarını değiştirmek onu daha fazla düşürdü. Çok parçalı bir proje için, 'scons' herhangi bir bağlantı yapmadan önce tüm derlemeleri yapabilir. Birden çok makefile kullanarak 'make', projenin bağlantılarından önce tek bir projenin derlemesini yapar, sonra devam eder.

Bu bizi tüm bireysel derleme komutlarının büyük ölçüde paralel yapılabileceği noktasına getirdi. Yavaş makinelerde 'distcc', çok çekirdekli makinelerde / scons -j8 yapın. Bu tam yapıları birkaç dakikaya indirdi.

Farklı bir ışık altında, otomatik bir gece oluşturma işlemi oluşturun. Bu şekilde kaynak deponuza sorunlu bir şey bağlanırsa, işe ilk gelen, sorunu gören ve düzelten ilk kişi, birden çok kişinin birden fazla başarısız derleme yapmasını engelleyebilir.

— Rick Berge
kaynak