Performans Hakkında Ne Zaman Düşünmeye Başlamalısınız?

Uygulamaları geliştirirken kendimi sürekli olarak bunun belirli bir işlevi gerçekleştirmek veya uygulamak için en iyi yol olup olmadığını sordum. Genellikle, stackoverflow veya geri bildirim isteyen başka bir forumla ilgili soruları yalnızca performansla ilgili olarak "attan önce arabayı koymama" hakkında yorum almak için gönderirim. Çoğu programcı gerçekten uygulama bitene kadar performans hakkında düşünmüyor musunuz, yoksa performans kesinlikle kabul edilemez mi ?? Yani, geliştirme ortamlarının üretim ortamlarından farklı olduğunu ve geliştirici dizüstü bilgisayarınızın sonuçlarına tamamen güvenmemeniz gerektiğini anlıyorum ... ancak, diğerlerinden daha iyi performans veren uygulamalar ve teknikler var.

Geliştirme süreci boyunca performansı dikkate almak kötü bir uygulama mı? Performans gerçekte tanker oluncaya kadar bu noktaları dikkate almalı mıyım ??

Güncelleme

Açık olmak gerekirse, düşündüğünüz durumdan ya da sadece bir işlevsellik üzerinde çalışmaktan bahsediyorum. Uygulamanın birkaç yolu olduğunu biliyorsunuz, ancak her uygulamanın ne kadar iyi ölçekleneceğinden emin değilsiniz. Ayrıca aşina olmadığınız birkaç teknik de olabilir. Küçük ölçekte yaklaşımlardan herhangi biri muhtemelen yeterli olacaktır, ancak daha büyük ölçekte bazıları devam edecek ve bazıları olmayacaktır. Genellikle fikir veya rehberlik istediğimde yanıt: daha sonra endişelenmek ...

Performans değerlendirmelerinin ertelenmesi bazen ifadenin yanlış uygulanmasına dayanır:

Erken optimizasyon tüm kötülüklerin köküdür.

Tam alıntıyı okursanız, Knuth'un söylemeye çalıştığı şey, profil oluşturma olmadan geliştirme sırasında uygulanan mikro-optimizasyonların genellikle tavsiye edilemez olmasıdır, çünkü bunlar önemli performans performanslarına ihtiyaç duymadan daha az sürdürülebilir koda yol açarlar.

Ancak bu, uygulama neredeyse bitene kadar performansı dikkate almamanız gerektiği anlamına gelmez. Bunu yaparsanız, performansın yetersiz olduğunu, tasarım mimarinizin daha iyi performansı desteklemediğini ve baştan başlamanız gerektiğini görebilirsiniz.

Ezoterik (ve erken) optimizasyonlar olmadan iyi performans elde etmek için geliştirme sırasında yapabileceğiniz birkaç şey vardır:

1. Mantıklı, iyi düşünülmüş bir mimari kullanın.
2. Veri yapılarını doğru kullanın.
3. Yeterli performans gösteren teknolojileri (kütüphaneler, çerçeveler) kullanın.

Bunları yaparsanız, gerçekleşmesi gereken herhangi bir performans optimizasyonunun kodunuzun küçük bir kısmı ile sınırlı olacağını göreceksiniz. Profil oluşturma, bu kodu belirler ve performans iyileştirmelerinizi, sürdürülebilirlikten ödün vermeden en iyi performansı gösterecekleri yere odaklamanızı sağlar.

İşte düşünmemeniz gerekenler:

• ++iDaha hızlı mı i++?
• switchDaha hızlı mı if?
• inlineİşlevlerimi yapmalı mıyım ?
• Sanal işlevler yavaş mı?
• C ++ / Java / C # diğerinden daha hızlı / daha yavaş mı?
• filan, filan, ...

İşte düşünmeniz gerekenler:

• Gerçekçi beklenen iş yükü nedir?
• Giriş bilgileri ne sıklıkta değişir ve bunu kim sağlar? Ön derlemeyi düşünmek mantıklı mı?
• Veri yapımı olabildiğince basit ve normalleştirdim mi? Bu, karma ve bunun gibi şeyler hakkında endişelenmemek anlamına gelir.
• Bildirimleri mutlak minimum düzeyde tuttum mu? (Bu, verilerin bir bölümündeki değişikliklerin başka bir bölümü için aynı anda değişiklik gerektirdiği, çünkü veri yapısı normalleştirilmedi.)

İkinci nokta ile ilgili olarak, deneyimime göre, veri yapısını, normalleştirilmemesi gerekiyorsa, daha sonra bir tür periyodik süpürme ile çözülebilecek geçici tutarsızlığı tolere edebilecek şekilde tasarlamak en iyisidir. Performansın önemli bir katili, bildirimlerin daha önce hiç tahmin etmeyeceğiniz ölçüde daha fazla tetikleyen başka bildirimleri tetiklemesidir. Ve genellikle kendini iptal eden değişiklikler nedeniyle çaba harcanıyor.

Tüm bunları yaptıysanız, temiz bir tasarıma sahipsiniz. Sonra periyodik olarak geliştirdikçe, profil. ( Rastgele duraklama , güvendiğim yöntemdir.) Ardından, daha karmaşık bir algoritma getirerek performansın iyileştirileceğini görebiliyorsanız, elbette bunu yapın.

Hayır başından itibaren performansı (özellikle veritabanlarını tasarlarken) düşünmelisiniz. Herhangi bir optimizasyonun erken optimizasyon olduğunu düşünen insanlar tarafından endüstrimize çok fazla zarar verilmiştir. Alıntı, orijinal olarak insanların bir sorun ortaya çıkmadan önce mikro optimizasyonlara bakmasını önlemekti. Hiçbir optimizasyon yapılmaması amaçlanmıyordu. Örneğin bir veritabanında, kötü performans gösteren birçok bilinen teknik vardır. Bunlardan kaçınmak, tasarımda yapmanız gerekenlerin bir parçasıdır. 100.000.000 kayıt içeren bir veritabanını yeniden düzenlemek çok zordur çünkü kötü performans gösteren teknikler kullanılarak tasarlanmıştır ve artık daha iyi donanım satın alarak sorunu önleyemeyiz.

Önce doğruluk ¹ , sonra sürdürülebilirlik, ardından güvenlik ve güvenilirlik hakkında endişelenin ve sonra performansı düşünebilirsiniz. Bu siparişi geliştirirken kodların her birine uygulayın. Performanslı bir çözümün doğal olarak işleri açık ve anlaşılır tutmaktan kurtulabilmesi mümkündür.

Performansın% 80'i mevcut problem için doğru algoritmayı ve veri yapısını seçiyor; kötü optimize bir quicksort hala ortalama durumda oldukça optimize kabarcık tür kapalı pantolon yenmek gidiyor (en kötü durumda bir beraberlik).

SO'daki herkesin şapırdamaya çalıştığı şey, insanların daha büyük sorunun izini kaybettikleri ve daha kırılgan, hataya neden olan kodla sonuçlanan derleyiciyi zekice yakaladıkları "daha hızlı, ++ p veya p ++" zihniyetidir. -köklü, yanlış ve en iyisi, daha basit bir çözümden daha hızlı değil. Bu tür kodlarla ilk elden başa çıktım; bir örnek o kadar kırılgandı ki, onu tamamen bozmadan hiçbir değişiklik yapamadık .

¹ "Doğruluk", "hatasız" ile eşanlamlı olmayan "spesifikasyonu yerine getirmek" anlamına gelir.

"İyi" performansın ne olduğunu öğrendikten sonra performansı düşünmeye başlamalısınız. Başka bir deyişle, aşağıdaki eşiklerin ne olduğunu belirlemeden önce performansı düşünmeye başlamak yanlış olur:

• Kabul edilemez performans - daha da kötüleşmeden şimdi düzeltin
• Kabul edilebilir performans - performansla daha fazlasını yapmaya çalışmadan önce diğer özelliklere odaklanma zamanı.
• Hedef performans - idealize edilmiş performans numaraları. Yani yeterli zamanınız ve kaynağınız varsa sisteminizin ne yapması gerekir?

Bu eşiklerin ne olduğunu belirledikten sonra, performansı ölçmek için kullandığınız metriği de belirlediniz. Bu, günde birkaç kez çalıştırabileceğiniz bazı otomatik performans testleri ayarlayabileceğiniz anlamına gelir. Bu size daha iyi veya daha kötü olup olmadığınızı gösterecektir.

Bu metrikleri bulmak için sisteminizin ne yapması gerektiğini anlamanız gerekir. Örneğin, mutlak performans metrikleri (X süresi içinde yanıt) için mi çağrılıyor veya iş hacmi ölçümleri (Y zamanı başına X yanıtı) için mi çağrılıyor? Verim ve mutlak zaman optimizasyonları farklı yaklaşımlar gerektirir ve gerçekten neyin önemli olduğunu bilmiyorsanız, yanlış yolu optimize ediyor olabilirsiniz.

Muhtemelen erken optimizasyonun tüm kötülüklerin kökü olduğunu duymuşsunuzdur. Soru onu erken yapan nedir? Bence, performansı düşünmek asla kötü bir fikir değildir, ancak kodunuz çalışana kadar aşırı endişelenmeyin. Çalıştıktan sonra, bazı ağır yük testleri yapın, darboğazları belirleyin ve tanımlayın ve performans optimizasyonlarınızı yapın.

Bununla birlikte, gerçek bir fark yaratacak belirli teknikleri biliyorsanız , ilk kodlama aşamasında performans hakkında düşünmenin yanlış bir yanı yoktur . Örneğin, geçmiş deneyimler size bunlardan birinin diğerinden daha hızlı / daha az RAM kullandığını öğrettiğinden, bir kütüphaneden diğerinden bir depolama yapısı seçmek. Ya da bildiğiniz veriler için basit bir önbellek sistemi oluşturmak (daha sonra test gerektiriyorsa daha karmaşık hale getirebilirsiniz)çok erişilir ve çok daha iyi önbelleğe alınır. Bu şekilde, performans hakkında çok fazla endişelenmiyorsunuz (en azından başlangıçta değil), ancak diğer projelerden öğrendiğiniz ipuçlarını ve püf noktalarını kullanıyorsunuz. Bunları basit tutmaya çalışın, böylece ilk geliştirme sırasında dahil edilmesi kolaydır ve bazı faydalar da sağlayabilirler.

Performans, Gereksinim Belgenizin sistem ve kullanıcı ile ilgili özelliklerinde ayrıntılı olarak belirtilmelidir. Birçok kişinin bir uygulamanın geliştirilmesinde Gereksinim Analizi yapma fikrini küçümsediğini biliyorum , ancak şaşırtıcı bir şekilde, uygulama tamamlanmaya yaklaştıkça performansla ilgili kaynaklarınızı neye ve nereye ayırmanız gerektiğine kısaca cevap verecektir. Ve bu soruya zamanında cevap verecek

Gereksinimler Belgeler, gerekli olmayan süreçlerde harcanacak yüzlerce saatlik zamandan tasarruf etmenizi sağlar.

Dengeli bir yaklaşım daha iyi olurdu. Performans önemlidir, ancak işleri halletmek kadar önemli değildir;

1. önce ne yaptığınız ve nasıl yaptığınız hakkında biraz düşünmeye çalışan bir özellik oluşturun (performans hakkında düşünmek için biraz zaman kullanın, ancak çok fazla değil)
2. Dene
3. bir kez çalışıyor daha iyi yapmak için gerçek bir ihtiyaç olup olmadığını düşünmeye başlayın (genellikle alışkanlık, ama bazı durumlarda olabilir).

Bu, performansa karşı işlevselliğe karşı ortak yaklaşımımdır ve genel olarak, programın ne yaptığına ve işlerin daha iyi çalışmasına ihtiyaç duyulup duyulmadığını ve bana ne kadar zaman harcadığını doğrulamaya bağlıdır.

Bunun gibi bir soru-cevap web sitesi düşünelim, arkasındaki olanlar kesinlikle bir soru sorma ve cevabı mümkün olduğunca en fazla zaman / maliyet perfomant alma hakkında çok düşündüm. Ancak, bildirimleri düşünürken, bildirimlerin arada bir görünmesi ve size yeni bir cevap veya başka bir şey olduğunu söylemek gerçekten önemli değildir.

Performans hakkında düşünmenin güvenli bir şekilde ertelenmesinin bir yolu vardır: mümkün olan yerlerde alana özgü diller kullanmak.

Gelişiminizin çoğu kendi küçük DSL'lerinizle yapılabilirse ve sorun alanınızı en genel ve üst düzey formda ifade edecek kadar iyi tasarlanmışlarsa, hiç düşünmeden önce çalışan bir prototip elde etmek mümkündür. performans ve ardından asıl sorun alan kodu değil, yalnızca DSL uygulamalarınızı geliştirin.

Veiw'in sürdürülebilirlik açısından da çok daha iyi bir yaklaşımdır.

Performansı dikkate almalısınız. Ancak, ayarın sonunu işaretlemek için bir çizgi çizmelisiniz, çünkü (genellikle) zamanınız bilgisayarınkinden daha önemlidir.

Performans hakkında gerçekten iyi bir metin makalesi: Bilgisayar Performans Kabuk Oyunu .

"Tıkanıklığı bul" olarak da bilinen bilgisayar performansı kabuk oyunu her zaman bu dört kaynak arasında oynanır:

• İşlemci
• Disk
• Ağ
• Hafıza

Herhangi bir anda, bilgisayarınız bu kaynaklardan birinde bir işlemin tamamlanmasını bekliyor. Ama hangisi: CPU, bellek, disk veya ağ? Performansla ilgileniyorsanız, yapmanız gereken ilk şey, bu darboğazlardan hangisinin şu anda performansı engellediğini belirlemek ve ortadan kaldırmaktır.

"En iyi" yol çok yüklü bir terimdir ve cevap, çalışma zamanına kadar bilinmeyen faktörlere bağlı olabilir.

• Bol miktarda hafızan var mı? - "all-in-memory" veri yapısı ile daha iyi performans elde edersiniz, ancak yeterli bellek değişiminiz yoksa performansınızı öldürür.
• Direnişe mi ihtiyacınız var? Bir veritabanı bütünlük sağlar, ancak yukarıdaki "all-in-memory" veri yapısından daha yavaştır. ÇOK daha yavaş.
• Sonuçları önbelleğe alabilir misiniz? Vernik bu konuda yardımcı olabilir! http://www.varnish-cache.org/

Liste uzayıp gidiyor.

Ne olabilir yapmak, bilgiden şu anda "belki iş olabilir en basit olanı" yazmaktır do var ve bunu yapmak modüler daha bile bile kolayca yeniden düzenleyebilirsiniz böylece moda. "En basit" şeyin mutlaka basit olmadığını unutmayın!

Her zaman aklınızda bulundurmanız gereken bir şeydir. Çoğu insanın söylemeye çalıştığı şey, iki gün harcamanın, bilmediğiniz bir şeyi optimize etmeyi denemek için çok fazla bir nokta olmadığını düşünüyorum. Bir ürünü çalışır hale getirdikten ve bazı kullanılabilirlik testleri yapabildiğinizde, bu size performans sorunlarının nerede olduğunu göstermelidir. Ardından, gerçek performans sorunlarını belirledikten sonra, gerçekleştirmeniz gereken optimizasyonları hedefleyebilirsiniz.

Teoride, en azından beta testine girdikten sonra performansı değil, performansı düşünmeye başlamalısınız.

Ancak bu kötü tasarım kararları verme lisansı değildir. Örneğin, bir NVARCHAR dizesini birincil anahtar olarak kullanmak, düşük performansa giden kesin bir yoldur; Bununla birlikte, performans sorunlarından bağımsız olarak pis bir alışkanlıktır ve ilk etapta kullanmamalısınız.

Tasarımınız geleneksel en iyi uygulamaları (3. normal formdaki her şey, sınıflarınızda doğru bilgi gizleme, tek tektonların minimum kullanımı vb.) Takip ederse ve daha sonra bir performans sorunu varsa, işlenmesi kolay olacaktır (burada bir dizin oluşturun, orada bir önbellek uygulayın).

HTH

Değişir. 80/20 kuralını akılda tutmak yararlıdır: uygulamadaki kodun çoğu (diyelim ki% 80), performansta gözle görülür bir fark yaratacak kadar sık ​​çalıştırılmaz. Uygulamanın yürütme süresinin yaklaşık% 80'ini harcamaya bağlı olduğu kalan% 20'ye odaklanmanız gerekir.

Belirli bir hesaplamanın milyonlarca kez yineleneceğini biliyorsanız, belli başlı performans sıcak noktalarından bazılarını önceden tanımlayabilirsiniz . Bu gibi durumlarda kesinlikle iş için doğru veri yapılarını ve algoritmaları seçerek bunu en iyi duruma getirmeyi düşünmeye değer.

Ancak, bu optimizasyon daha çok bir tasarım faaliyetidir. Genellikle değersiz olan, birisinin "performans kazanmak" adına akıllıca bitkin hilelerle olağanüstü bir zaman geçirdiği mikro optimizasyonlardır. Özellikle önce ve sonra uygun ölçümler olmadan yapılırsa, bu değişiklikler herhangi bir fark yaratmayabilir veya gerçek yaşam koşullarında uygulamayı yavaşlatabilir.

Hangi gelişim aşamasında olduğunuza bağlıdır

1) Yazılımınızın işlevselliğini geliştiriyorsanız, çalışmaya devam edin ve iyi çalıştığından emin olun (yani, istenen ve verimli).

2) Yapı taşları entegre edildikten sonra, kaynak hogger ipucu alacaksınız, orada optimizasyon için yer var.

Performans hakkında düşünmeye başlamak zorunda kalırsanız, başınız belada. Performansı her zaman düşünmelisiniz. Aslında, iyi programcıların, “erkekler her yedi saniyede bir cinsellik hakkında düşünüyorlar” modasında bile, performansı düşüneceklerinden şüpheleniyorum.

Önemli olan , tüm bu düşünceye dayanarak hangi önlemleri alacağınızdır. Düşünceler ucuzdur, ancak eylemler kodu kırabilir ve son başvuru tarihlerini patlatabilir.

Çoğu zaman, tek mantıklı eylem hiçbir şey yapmamak olacaktır: kod parçanızın performans sorunlarının gözlemlenebilir olması için yeterince sık çağrılmayacağını belirlediniz - belki de bilgisayar başına bir kez çalışan bir başlangıç ​​kodu parçası Potansiyel kullanıcı tabanınızın% 1'i, belki de yavaş veritabanı erişimleri denizinde boğulmuş küçük bir yedek sunucu kodu, belki de kodun kritik olmayan bir bölümünde sadece bir tamsayı atamasıdır.

Çoğu zaman, belirli bir işlemin basit bir değişiklikle çözülebilecek bir performans sorununa neden olabileceğinden şüphelenirsiniz. Örneğin, her istekte karmaşık bir SQL sorgusu çalıştırmanın veya bir sözlükten iki kez aynı veri parçasını istemenin sizin için kötü olacağı rahatsız edici bir his var. İşte bu noktada optimizasyon tekniklerinin bilgisi işe yarıyor ve belki de en şaşırtıcı sonuç ortaya çıkıyor:

Bir kod parçasının performansını neredeyse kesinlikle artıracak hızlı bir teknik biliyorsanız, bunu yapmayın.

Şimdi düşünebiliyorsanız, kesinlikle beş dakika sonra yapabilirsiniz. Kodu dışında tutmak (ama belki de bir // TODOyorumda), kodu temizler ve başka bir özellik üzerinde çalışmak için önceki zamandan tasarruf etmenizi sağlarken, daha sonra bu kodu atmak için zaman kaybetmezsiniz. Orijinal kod test edildiğinde performans sorunlarına neden oluyorsa geri dönün ve hızlı tekniğinizi uygulayın.

Burada sadece daha hızlı olması nedeniyle deyimsel kod yazmaktan kaçınmalısınız demiyorum. Üretkenliği ve okunabilirliği artıran ve hataları azaltan en iyi uygulamalara göre deyimsel kod yazın. Sadece idiyomatik kitap kodu ile daha hızlı ama kolay yazılan bir alternatif arasında seçim yapabiliyorsanız, her zaman hız yerine okunabilirliği tercih edin.

Tek zor durum, kod performansını iyileştirmenin kolay bir yolu olmadığı ve yine de bir kod parçasının teslim edilir edilmez kırılacağı açıktır - her tıklamada tam bir veritabanı geçişi, yüz SQL isteği sitedeki sayfa başına veya benzer şekilde korkunç bir şey. Burası biraz daha durup düşünmeniz gereken yer. Bunlar genellikle yerel ölçekte çözülemeyen mimari meselelerdir. Şüphelerinizi hızlı bir artış veya prototiple onaylayın, benzer deneyimleri ve ortak çözümleri arayın ve mimaride bir değişikliği veya bir özellik düşüşünü düşünün.

IMHO sistemi uygulamadan önce performansı düşünmek önemlidir, ama sadece düşünün. Uygulamayı analiz etmeli ve potansiyel performans darboğazlarının neler olabileceğini öğrenmelisiniz.

Ardından sistemi olabildiğince basit uygulayın. Performans sorunları ortaya çıkarsa, optimize edin.

Örneğin, bir tür hizmetten (SOAP, REST HTTP, vb.) Veri alan bir GUI istemciniz olduğunu varsayalım. Daha sonra yüksek performans / ölçeklenebilirlik için en önemli şey, her çağrının çok fazla veri döndürmesini sağlamak yerine mümkün olduğunca az çağrıya sahip olmaktır, daha çok çağrıların her biri küçük bir bilgi döndürerek, yani tıknaz iletişimi konuşmaya tercih eder.

Bu tür bir sistemi uygularken, sistem arasındaki çağrıların sayısını umursamam. Ancak, kod tabanının, ihtiyaç duyulduğunda yeniden düzenleme / optimizasyon yapmamı kolaylaştıracağından emin olurum.

Performansı en başından itibaren genel olarak düşünmelisiniz. Uygulamanız için iyi çalışan ve makul düzeyde verimli olacak veri yapılarını ve algoritmaları seçmelisiniz. Algoritmalar yazılım ve veri yapıları için daha önemlidir. Her ikisinde de büyük değişiklikler yapmanız gerekiyorsa büyük yeniden yazma işlemleri yapmanız gerekecektir, ancak daha küçük ayrıntılar daha kolay yeniden yazılabilir.

Ayrıca etkili alışkanlıklar edinmek isteyebilirsiniz, ancak bunlar dile bağlı olacaktır. C ++ 'da, örneğin, "++ i;" tek başına bir ifade veya ifade her zaman en azından "i ++" kadar iyidir ve potansiyel olarak çok daha verimli olabilir. Bununla birlikte, çoğu durumda, açık kod yazmalı ve derleyiciye güvenmelisiniz. Mikro verimlilik konusunda endişe etme alışkanlığına girmek neredeyse kesinlikle çözdüğünüzden daha fazla soruna neden olacaktır. Masaüstü uygulamaları için, derleyici en azından i >> 1vs. gibi şeyler hakkında akıllıdır i / 2veya performansı artırmanın en iyi yolu daha iyi bir derleyici elde etmektir, bu yüzden endişelenmeyin.

Bunun ötesinde, test edebileceğiniz bir şey olana kadar fazla endişelenmeyin. O zaman, etkin noktaların nerede olduğunu görmek için programı profille ve muhtemelen bir performans programınız olup olmadığı hakkında bir fikir edinebilirsiniz. Performansı artırmanız gerekiyorsa, programın zamanının çoğunu nerede harcadığını bulun ve orada işleri iyileştirin. Yeterli küresel verimlilikte tasarladıysanız ve programı iyi yazdıysanız, programın yalnızca nispeten küçük bir bölümünü değiştirirsiniz.

Bence yapabileceğiniz en iyi şey, bir şey işe yarayana kadar iyi tasarım uygulamalarını (örn., Bildiğiniz şeyleri performansı engelleyecektir) takip etmektir. İyileşmeyi ölçemezseniz, iyileştirme yapamazsınız. Test edebileceğiniz bir şey elde ettikten sonra, profil oluşturma çalışması yapmak ve sıcak noktaların (varsa) nerede olduğu hakkında bir fikir edinmek genellikle iyi bir fikirdir. Bir şey size sıçrarsa, sorunlu alanı yeniden düzenlemeyi veya yeniden yazmayı düşünmelisiniz, ancak çok kötü değilse (kodun iki veya üç yöntemde zamanının% 90'ını harcaması, yeterince genel performans göstermesi anlamına gelmez) o zaman gelişmeye devam edin. Birden fazla gördüğüm şey, sistemin en karmaşık kısmını optimize etmek için gün harcayan geliştiriciler,

Ne zaman düşünmeye başlamalıyım? Ne kadar çaba harcamalıyım? Bu , projenin Cockburn Ölçeğine bağlıdır . (Başka bir deyişle, iyi performans göstermeme riski nedir?)

Temel bilgileri önceden öğrenin (Robert Harvey'nin cevabına bakınız ). Yazılım geliştirme sürecinin çeşitli aşamalarında performans odaklı düşünmeyi uygulamak için, geliştirici bunu içten dışa bilmek zorundadır, böylece düşünce süreci bu ekstra hususlar tarafından engellenmez. (Başka bir deyişle, proje tasarlanmadan önce performansı düşünmeye başlayın.)

Gelişimin erken safhasında, performans profili oluşturma araçlarını serbestçe kullanın ve istatistik geçmişini takip edin. Bu bilgileri daha sonra karar vermek için yararlı hale getirmek için düzenlemeye özellikle dikkat edin.

Ardından, projenizin doğasına ve Cockburn Ölçeğine bağlı olarak:

• Hızlı Prototipleme veya "yarın yokmuş gibi kodları patlatın" veya iş etkisi düşük olan şirket içi geliştirme: sadece istatistikleri koruyun. Henüz performansı düşünmeyin. İşlevi en kolay şekilde uygulayın. Aklınıza gelen ilk algoritmaya sadık kalın.

  • Projenin sonraki yarısında, gerçek kullanım durumlarına göre "sıcak noktaları" tanımlamak için geçici performans testi yapılacaktır. Yazılımı kullanılamaz hale getiren herhangi bir performans sorunu varsa, kolayca tanımlanabilir olmalıdır.
  • İş etkisi düşük olan şirket içi geliştirme için, kodu konuşlandırın ve performans sorunlarını daha sonra düzeltin.

• Performansa tutarlı, çok yönlü bir yaklaşım gerektiren masaüstü uygulamaları. Yüksek düzeyde optimize edilmesi gerekmez; ancak, mümkün olduğunca az sayıda "kilitlenme" (yanıt vermeme) olmalıdır.

  • Masaüstü uygulamaları genellikle performans odaklı düşünmeyi zorlaştıran oldukça kıvrımlı yürütme yollarına sahiptir. Katmanlı bir tasarım, Veritabanı / Ağ performans sorunlarının GUI performans sorunlarından ayrılmasına ve ekibinizdeki farklı uzmanlar tarafından ele alınmasına izin verecektir .
  • Günlük izlerinin geçmişi etkin noktaların tanımlanmasına izin verecektir.

• Donanımdan en iyi performansı almayı gerektiren yüksek performanslı bilgi işlem.

  • Performans istatistiklerini analiz etmek ve raporlamakla sorumlu olacak şekilde ekibinizden birini atayın.
  • Performans özellikleri hakkında teoriler oluşturun, deneylerle doğrulayın ve basitleştirilmiş Comp Sci modellerindeki tahminlerinizle karşılaştırın.
  *

Başlangıçta. Gerekli performans özelliklerini belirleyin. Hedefi belirleyemiyorsanız, gereksinimlerinizi daha iyi anlamak için geri adım atmanız veya bileşen gereksinimlerinizi yeniden yazma riskiyle karşılaşana kadar ertelemeniz gerekir. Sonra test edin. Optimize etmeyin, test edin. Kodunuz performans testinde başarısız olursa, optimize edin. Bir test çerçevesi mevcut olduğunda, mevcut performans izleme araçlarının kullanımı görevi oldukça kolay hale getirmelidir.

Bir regresyon testi olarak projenin ömrü boyunca performans testlerini yerinde tutun. 'Düzeltmeler' genellikle çok dar bir odağa sahip olduğundan, bakım kodu performans sorunlarını tetiklemekle ünlüdür.

Her zaman basit bir formüle güvenirim:

1. Çalışmasını sağla
2. Doğru yap
3. Hızlı yap

... bu sırayla.

C2'ye göre , bu formülasyon Kent Beck'e atfedilmektedir .