Uzun derlemeler geçmişte kaldı mı?

Bir derlemenin ne kadar süreceği konusunda sayısız savaş hikayesi var. Xkcd bile bundan bahsetti.

Şimdi, uzun zamandır programlama yapıyorum ve çoğunlukla Java ve Python'a maruz kaldım (ve Python derlenmiş bir dil değil, yorumlanmış bir dildir). Derlemesi çok uzun süren projelerle karşılaşmamamın mümkün olduğunu anladım, ancak düzgün boyuttaki uygulamalar için bile, ya benim için anlık oldu (genellikle bir IDE tarafından arka planda ele alındı) ya da 30'dan fazla almadı. Çok büyük bir proje için saniyeler ya da öylesine. Bir iş ortamında bile (çizgi romanın gerçekleştiği yer), kodun derlenmesi bu kadar uzun sürmedi.

Derleme süreleri uzun olan projelere henüz maruz kalmadım mı? Bu, artık günümüzde olan bir şey olmayan geçmişin bir kalıntısı mıdır? Bir derleme neden bu kadar uzun sürdü?

Derleme, özellikle C, C ++ veya Scala gibi dillerde yazılmış büyük projeler için biraz zaman alabilir. Arka plandaki parçaları derlemek derleme süresini azaltabilir, ancak bazen yeni bir derleme yapmanız gerekebilir. Uzun derleme sürelerine yol açabilecek faktörler şunlardır:

• Açıkçası büyük kod boyutu. Büyük projelerde yüz binlerce kod satırı olacaktır.

• C'nin #includeaynı kodun yüzlerce kez derlenmesini sağlayan önişlemci yönergesi. Makro sistemde, metin düzeyinde çalıştığı gibi benzer sorunlar var. Önişlemci gerçekten derleyiciye iletilen kod boyutunu şişiriyor. Ön işleme tabi tutulduktan sonra bir dosyaya bakmak (örn. Üzerinden gcc -E) gözlerinizi açmalıdır.

• C ++ 'ın şablonları Turing tamamlandı, yani teoride derleme zamanında rastgele hesaplamalar yapabilirsiniz. Kimse gerçekten bunu yapmak istemez, ancak birçok basit durum bile şablonları özelleştirmek için harcanan zamana katlanır.

• Scala oldukça genç bir dildir ve derleyici çok az optimize edilmiştir. Şu anda, derleyici çok sayıda derleme geçişi kullanmaktadır (C yalnızca iki derleme geçişi gerektirecek şekilde tasarlanmıştır). Typechecking bu geçişlerden biridir ve dilin sahip olduğu karmaşık tip sistem nedeniyle biraz zaman alabilir.

Derleme zaman alan tek şey değil. Proje derlendikten sonra bir test takımı çalıştırılmalıdır. Bunun için harcanan zaman birkaç saniye ile birkaç saat arasında değişebilir (eğer testler kötü yazılmışsa).

Hiçbir şekilde geçmişin kalıntısı değil. Üzerinde çalıştığım projelerden biri sıfırdan temiz bir yapı için 45 dakikaya ihtiyaç duyuyor. Kendi kodumuzun yanı sıra, kaynağı birçok büyük C ve C ++ kütüphanesinden harici depolardan çekip almamız gerekiyor. C ve C ++ kodlarının derlenmesi ve bağlanması işlemsel olarak pahalıdır. İşaret ettiğiniz gibi, Python tipik olarak tercüme edilmiş bir dil olarak uygulanır ve Java genellikle bir JIT (Tam Zamanında) derleyicisi kullanır, bu nedenle projeleriniz ön plana çıkan derlemeleri atlar ve maliyetleri tamamen birbirine bağlar. Ödediğiniz fiyat daha uzun başlangıç ​​sürelerinde ve (en azından Python için) daha düşük uygulama hızıdır.

Derleme süreleri uzadıkça, Jenkins veya TeamCity gibi sürekli entegrasyon sistemlerinden yararlanmak daha önemli hale gelir . Bu, bireysel geliştiricilerin (çoğunlukla) binanın sıfırdan çıkmasını önlerken, değişikliklerin yapıyı bozmadığını sınamaktadır.

Büyük projeler uzun zaman alabilir. Yeterince büyük bir proje için bir saat veya daha fazla olabilir. Bilgisayarımdaki kaynaktan çok uzun zaman alan bir derleme yapmam gereken bir kaç kütüphane var - örneğin opencascade. Linux çekirdeğinin kendisi de, sıfırdan inşa etmeniz gerektiğinde oldukça uzun zaman alıyor.

Bununla birlikte, çok daha uzun sürebilecek başka derleme benzeri işlemler vardır. Dijital devre tasarımı (ASIC'ler veya FPGA'lar için) bir yer ve rota adımı gerektirir. Yer ve rota adımı, bireysel mantık kapılarının, flip-flop'ların, yazmaçların, RAM'lerin ve diğer bileşenlerin yerleştirilmesinin, ara bağlantı kablolarının yönlendirmesi ile birlikte belirlendiği yerdir. Yazılım, olası yerleşimler için geçit ve yönlendirme gecikmelerini belirlemek için zamanlama modellerini kullanır, bunları zamanlama kısıtlamaları tarafından sağlanan sınırlarla karşılaştırır ve ardından zamanlama gereksinimlerini karşılamayı denemek için yerleştirme konumlarını ve kablo yollarını ayarlar. Bazen yazılımın zamanlamayı karşılamak için kapıları yeniden boyutlandırması ve arabellek eklemesi gerekebilir. Bu adım, hesaplama açısından oldukça yoğundur ve tamamlanması birkaç saat hatta gün sürebilir. Aynı zamanda pek iyi paralellik göstermiyor. Yaklaşık bir yıl önce üzerinde çalıştığım bir FPGA tasarımı vardı ve yaklaşık bir Virtex 6 HXT 565 FPGA'nın (yaklaşık 565k LUT'dan 300k) tükettiği ve yer ve güzergahın tamamlanması yaklaşık 7 saat sürdü. Çekirdek i7 CPU tasarımı gibi bir şey üzerinde yer alıp rotalamanın ne kadar süreceğini hayal bile edemiyorum - muhtemelen en az birkaç hafta.

Diğer cevaplar, büyük olasılıkla 500k satır ve üstü anlamına gelen büyük projelere ilişkin kodun, özellikle de sıfırdan inşa edildiğinde, önemli zaman alabileceğini belirtmiştir.

Ek nokta, bazı projelerin birden fazla hedef ortam için inşa edilmesi gerektiğidir. Bu ortamları barındıran makineler mevcut olmadığında, yapı sahip olduğunuz makineler üzerinde seri olarak çapraz derleme ile yapılmalıdır. Bu önemli inşa sürelerine yol açabilir . Üzerinde çalıştığım bir proje için, gece inşaatı 10 saat sürecek. İhtiyacı olan, sen onu kıran bendim

Zaman kaybetmek için böyle bir bahane ile kaçamayacağınızı da eklerim. Onlar böylece profesyonel kişi görevlerini planlama gerektiğini do böyle dönemlerde yapılacak işe yarar bir şey var.

İkisinden de biraz. C ++ (ve daha az oranda C) yavaş derleme süreleriyle, özellikle de dönem donanımlarıyla ünlüdür. Milenyumun etrafında, makro şenanlar nedeniyle inşa edilmesi yaklaşık 4 saat süren bir proje üzerinde çalıştım.

Bugünlerde işler daha iyi, ancak deneyimimde 30 saniye oldukça düşük - özellikle, kaynak kontrolünden, ünite testlerinden, montajcılardan ve bazı SAN'lara bir yerden gönderilen her şeyden kontrol edilmesi gereken resmi yapılarda.

Bu, projeye ve derlendiği ortama bağlıdır. Derlemesi birkaç dakika süren C ++ projeleri üzerinde çalıştım (MSVS'de çoklu projeler olarak ayarlandı).

Büyük bir kod ve veri tabanına sahip büyük bir şirket (Proctor ve Gamble, Google, vb.) Veya çok karmaşık olan bir veya iki ana ürüne odaklanan küçük bir şirket veya başlangıç ​​için çalışıyorsanız (örneğin, bilimsel simülasyon ve görüntü oluşturma), o zaman büyük bir projenin derlenmesini beklemek, güçlü makinelerde bile beklenebilecek gerçekçi bir şey. Bu, kodunuzu nasıl geliştirip hata ayıkladığınızı (ve sürümleme yoluyla değişiklikleri ne sıklıkta güncellemeyi ve birleştirmeyi seçtiğinizin) etkileyebilir.