Herkesin yazılımın daha hızlı çalışmasını sağlamak için herhangi bir fikri deneyebileceği bir zaman dilimi mi teşvik ediyorsunuz?

Bazen yazılım performans hileleri metodolojik ve kapsamlı bir aramada bulunur. Bazen çılgın fikirleri denemek için farklı düşünme ve cesaret gerektirir. Bazen bir fikir, çok fazla çalışma ile takip edilmesi gereken başlangıçtır.

Üzerinde çalıştığımız yazılımın performansını artırmak için herkesin farklı fikirler deneyebileceği bir zaman dilimi nasıl desteklenir? Takımdaki herkes yazılımla ilgili en az birkaç ay deneyime sahiptir ve bu yazılımda çok iyidir.

Farklı düşünmenin yazılım performansını artırmanın yollarını bulmaya yardımcı olacağını kabul ediyor musunuz? Neden? Neden olmasın?

Hangi teknikler bir optimizasyon fikrini hızlı bir şekilde denememizi sağlayacaktır? Denemeden iyi sonuçlar almak için hızlı kodlama hızı gerekli midir?

Son olarak, gevşeme olasılığı yaratmadan iyi sonuçlar elde etmek için ne kadar "zaman" ayrılmalıdır?

"Bir şeyi yapmanın daha hızlı bir yolu" nun var olduğunu kanıtlamak için deneyler gerekli mi? (2011-06-07 eklendi)

İlişkili:

• Takımınızın seviyesini zekice geliştirecek stratejileriniz nelerdir?
• Kod saldırıları ne zaman kötüleşir?

( Sadece ödül amaçlı -2011/06/07 için takım büyüklüğü 2-4 geliştiricidir, özel KG yoktur. Geliştiriciler tarafından yapılan tüm kod, birim testi ve performans testi. Projenin doğası nedeniyle profiler sonucu göstermede yararlıdır tek bir darboğaz açmasa bile oransal yürütme süresi.)

En iyi seçeneğiniz, etkin noktaları bir profil oluşturucu ile tanımlamak ve - bir ekip olarak - etkin noktaları nasıl düzelteceğinizi tartışmaktır.

Gelişmeyi ölçebilmeli ve belgeleyebilmelisiniz (bu yüzden sadece vahşi tahmin değil) ve bunu bir ekip olarak yapmak, insanların neyin sabit olduğunu ve nasıl yapıldığını bilmelerini sağlar.

Programcıların fikirleri denemek için kod tabanına çılgınca saldırması, neler olup bittiğini ve çalışıp çalışmadığını kontrol edemediğiniz anlamına gelir.

Programcılar akıllı ve yaratıcı olma eğilimindedirler (bunlar programlamada iyi olmak için ön koşullardır), bu yüzden sorunları çözmeye çalışırken çok çeşitli fikirleri denemelerine izin vermek her zaman iyidir. Ancak performansı artırmaya çalışırken hatırlanması gereken iki şey vardır ("performans" ile yürütme hızını azaltmayı kastediyorum):

• Algoritmik optimizasyonlar her şeyden çok daha iyi çalışma eğilimindedir. Önemsiz bir örnek olarak, bubblesort uygulamanız için ne yaparsanız yapın, yeterli sayı ile hızlıca son derece yavaş bir uygulama sonunda daha hızlı olacaktır.
• Performansla ilgili herhangi bir şey yapmak, sonuçları ne yaparsanız ölçmeyin (profil oluşturmayın) ve temel almadıkça tamamen saçmadır.

Ana nokta, vahşi deneylere başlamadan önce bu konularla ilgili herkesle aynı sayfada olduğunuzdan emin olmanız önemlidir . Daha sonra, daha az deneyimli iş arkadaşlarınızın asla işe yaramayacak şeyleri denediklerini öğrenmek her zaman utanç vericidir (ve önlerinde onlara söyleyebilirdiniz).

Ne yazık ki, deneyimden konuşamam. Ancak Atlassian'ın, çalışanların istedikleri her şeyi yapmalarına izin verildiği ve fikirlerini bir tür parti atmosferinde sundukları tek bir günü olduğunu duydum . Görünüşe göre onlar için iyi oldu. Ancak Andersen ile hemfikirim ve performans söz konusu olduğunda, yaratıcı ve hazır fikirlerin hangi süreçlerin en çok zaman aldığını profillemekten daha az önemli olduğunu söylemeliyim. Belki bir kez sisteminizi profilledikten sonra, sürecin önemli bölümlerini hızlandırmaya nasıl yardımcı olacağınız konusunda fikir edinmek için herkese bir gün verebilirsiniz. Fikirlerini sunduktan sonra, hangilerini deneyeceğinizi seçebilirsiniz.

Önceki takımlarımdan bazılarında yaptığımız başarılı bir uygulama Deep Dives konseptine sahip olmaktı. Birkaç kişi bir konferans odasında bir araya gelecek, bazı kullanıcı senaryolarını belirleyecek ve ya koddan geçmeye ya da profil kayıtlarına bakmaya başlayacaktır. Bazı durumlarda, veriler şüphecileri kendi kodlarında gerçekten mükemmel konular olduğuna ikna etmemizi sağlayan darboğazları açıkça gösterdi! Bunu başarılı kılmak için takip ettiğimiz bazı temel ilkeler vardı:

1. Darboğazlardan şüphelenilen kritik senaryolara veya kod yollarına odaklanmaya çalışın. Optimize edilmesi gerekmeyen şeyleri optimize etmek için zaman kaybetmeyin (eğer kırılmazsa ...)
2. Grubu küçük tutun ve kodu en iyi bilen insanlara odaklanın. Özelliğin test kullanıcısını ve program yöneticisini dahil etmeyi unutmayın - kilit öngörüleri vardır ve daha iyi test edebilmeleri için katılımcı veya bilgi toplamaktan yararlanabilirler.
3. Bölge sahibine üst düzey bir mimari blok seviyesi diyagramı ve alana genel bakış sunarak oturuma başlayın. Anahtar bileşenler nelerdir ve ne yaptıklarını kısaca açıklarlar. Kod içine girdikten sonra blok diyagramın kaç kez gerçeği yansıtmadığına şaşıracaksınız. (Gerçek alıntı: "Hala o bileşeni kullandığımızı bilmiyordum. O yıllar önce kurtulduğumuzu düşündüm!")
4. Mükemmel sorunların yanı sıra fonksiyonel hatalar bulmayı bekleyin. Bu iyi birşey. Ayrıca, bazen önemli bir şey bulamayacağınızı düşünün. Bu da iyi bir şey olabilir.
5. Birkaç uzun oturumun gerçekleşmesini bekleyin. Bunlar çalışma toplantıları. Rahat olun ve üzerinde çalışın. Uzun süreli uzanmalar için ortak çalışabildiğinizde çok daha fazlasını yaparsınız.
6. Notlar al, iyi notlar. Bir hata izleme veritabanı kullanıyorsanız, düşük öncelikli olsalar bile sorunları takip etmek için hemen açmayı düşünün.

Tüm ekibin "Performance Push" a katılmasını önleyin. Bunlar genellikle Thorbjørn Ravn Andersen'in başka bir cevapta bahsettiği nedenlerden dolayı yönetimin beklediği sonuçlara sahip değildir . Bazı alanlarda büyük kazançlar elde edersiniz, insanların aşina olmadığı diğer alanlarda gerilemeler görürsünüz ve "işiniz bitti" demek için ne kadar kazanç elde etmeniz gerektiğini tahmin etmek / izlemek zordur. Bu, yönetim ile yapılması zor bir sohbet.

Yazılımınızın hızını artırmanızın nedeni, içindeki bir şeyin fark edilir derecede yavaş olmasıdır. Durum böyle değilse, optimizasyon zaman kaybıdır. Ancak bir şey yavaşsa, o zaman görevi yapın.

... Ve görevi yapmak için, bu sırayla iki adım var:

1. Görevi yapan işlevin verimli bir şekilde yazılıp yazılmadığına bakın. İyi veya zayıf bir algoritması var mı? Veritabanına verimli bir şekilde erişiyor mu? Bir kez yapılabileceği zaman 100 kez dönüyor mu? Genellikle, kodun basit bir şekilde incelenmesi, bir engeli bulabilir ve sadece düzeltmekle kalmaz, aynı zamanda sizi daha iyi bir programcı yapar.

2. 1 numaraya bir saatten fazla zaman harcamayın. Sorunu bir saat içinde bulamazsanız, söz konusu noktayı bulmak için bir profil oluşturucu kullanın. Sorunlu noktayı öğrendikten sonra, 1 numaraya geri dönüp bunu tekrar yaparak tanımladığınız kodu geliştirmenin en iyi yolunu bulmak için aşağı inebilirsiniz.

Genel olarak (**) deneylerle daha iyi performans elde edemezsiniz.

Anladın mı

• Başlamak için basit, verimli bir tasarımın nasıl yapılacağını bilmek. Bu kısmı yanlış anlarsanız, deney çok fazla fark etmez. Örneğin, bir kod üreteci kullanırken nasıl söyleyeceğinizi bilmek kazanan bir tasarım yaklaşımıdır.

• A) yüzde bazında pahalı ve b) daha iyi bir şeyle değiştirilebilecek etkinlikleri bularak yazılımı nasıl ayarlayacağınızı bilmek. Herkes "profiler kullanmanız" gerektiğini biliyor ama bu yeterli değil.

Diğer sorunuzun yanıtını kontrol edin.

** İstisnalar, grafik oluşturma, işlemci ardışık düzen veya CUDA davranışı gibi sıkı donanıma bağlı kodlar veya ağ veya DB protokollerini denemek olabilir; burada en iyi şekilde kullanmanız gerekir.

EKLENDİ: Büyük sistemlerin birçok programcısının şaşırtıcı bulduğu bir şey var. Mükemmel, iyi yapılandırılmış büyük programlarda, büyük, görünmez performans sorunları olabilir ve profilciler rutinlere yerelleştirilmedikleri için bunları bulamazlar. Program en iyi tarzda yapılabilmesine rağmen, programın genel yapısının bir parçasıdır.

Sadece somut bir örnek vermek gerekirse, iş yapan kaynak kodu (C ++ 'da) olan bir program . Üzerinde çalıştığım gerçek bir C programından damıtılmıştır.

Yapılması amaçlanan şeyi yapar, ancak zamanının hangi kısmını gerçekten gerekli değildir ? Ne kadar hızlandırılabilir?

Programın ilk versiyonunda, mükemmel mantıklı görünen ve yerel olmayan bir şey (bir profiler için görünmez) zamanın% 33.3'ünü alıyordu. Değiştirildiğinde, o zaman kaydedildi ve bu programın ikinci versiyonuydu.

Programın ikinci sürümünde kaldırılabilecek başka bir şey (herhangi bir profil oluşturucu tarafından görülemez) zamanın% 16,7'sini alıyordu. Çıkarılması sürüm 3'e yol açtı.

Sürüm 3'te% 13 çıkarıldı. Geriye kalanların% 66'sı çıkarıldı. Bundan sonra kalanların% 61'i çıkarıldı!

Sonunda, bundan sonra kalanların% 98'i kaldırıldı!

Peki büyük resim nedir? Orijinal program tarafından harcanan her 1000 döngüden kaç tanesi kaldırıldı? 998!

Her program farklıdır, ancak her büyük programın tecrübelerime göre, profil kullanıcılarının bulamayacağı, manuel örneklemenin bulacağı ve programcılar gerçekten maksimum performansa gidecekse kaldırılabilecek bir dizi zaman ayırma sorununa sahiptir. büyük hızlandırmalar için.