Erken optimizasyon gerçekten tüm kötülüklerin kökeni midir?

Bugün bir meslektaşım, ThreadLocalFormattemelde Java Format sınıflarının örneklerini yerel bir iş parçacığına dönüştüren bir sınıf işledi , çünkü iş parçacığı güvenli ve "nispeten pahalı" olmadı. Hızlı bir test yazdım ve saniyede 200.000 örnek oluşturabileceğimi hesapladım, kendisine "hiçbirine yakın hiçbir yerde" yanıtladığı o kişiyi yarattığını sordum. O harika bir programcı ve takımdaki herkes çok yetenekli, bu yüzden sonuç kodunu anlamada sorun yaşamadık, ancak açıkça ihtiyaç duyulmayan bir yerde optimizasyon yapılması durumuydu. İsteğim üzerine kodu geri aldı. Ne düşünüyorsun? Bu bir "erken optimizasyon" durumu mu ve gerçekten ne kadar kötü?

Tam alıntı akılda tutulması önemlidir:

Küçük etkinlikleri unutmalıyız, zamanın% 97'sini söyleyelim: erken optimizasyon tüm kötülüklerin köküdür. Yine de, bu kritik% 3'teki fırsatlarımızı kaçırmamalıyız.

Bunun anlamı, ölçülen performans sorunlarının yokluğunda, optimizasyon yapmamanız gerektiği çünkü performans kazancı elde edeceğinizi düşünüyorsunuz . Belirgin optimizasyonlar var (sıkı bir döngü içinde dize birleştirmeyi yapmamak gibi), ancak çok net bir optimizasyon olmayan herhangi bir şey ölçülene kadar kaçınılmalıdır.

"Erken optimizasyon" ile ilgili en büyük sorun beklenmedik böcekleri ortaya çıkarabilmesi ve çok büyük bir zaman kaybı olabilir.

Erken dönem mikro optimizasyonlar tüm kötülüklerin kökenidir, çünkü mikro optimizasyonlar bağlamı dışlar. Neredeyse asla beklendiği gibi davranmazlar.

Önem sırasına göre bazı iyi erken optimizasyonlar nelerdir:

• Mimari optimizasyonlar (uygulama yapısı, birleştirilme ve katmanlanma şekli)
• Veri akışı optimizasyonları (uygulamanın içinde ve dışında)

Bazı orta geliştirme döngüsü optimizasyonları:

• Veri yapıları, gerekirse daha iyi performans gösteren veya daha düşük ek yüke sahip yeni veri yapıları sunar
• Algoritmalar (şimdi quicksort3 ve heapsort arasında karar vermeye başlamak için iyi bir zaman ;-))

Bazı son geliştirme döngüsü optimizasyonları

• Kod noktaları bulma (en iyi duruma getirilmesi gereken sıkı döngüler)
• Kodun hesaplamalı bölümlerinin profil temelli optimizasyonları
• Mikro optimizasyonlar artık uygulama bağlamında yapıldıkları gibi yapılabiliyor ve etkileri doğru bir şekilde ölçülebilmektedir.

Tüm erken optimizasyonlar kötü değildir, geliştirme yaşam döngüsünde yanlış zamanda yapılırsa mikro optimizasyonlar kötüdür , çünkü mimariyi olumsuz etkileyebilir, başlangıçtaki verimliliği olumsuz etkileyebilir, ilgisiz performans gösterebilir veya sonunda zararlı bir etkiye sahip olabilir farklı çevre koşulları nedeniyle gelişme.

Performans kaygılanıyorsa (ve her zaman olması gerektiği gibi) daima büyük düşünün . Performans daha büyük bir resimdir ve şu gibi şeyler hakkında değil: int kullanmalı mıyım yoksa uzun mu kullanmalıyım ? Aşağı Yukarı yerine performansla çalışırken Yukarı Aşağı gidin .

İlk ölçüm olmadan optimizasyon neredeyse her zaman erkendir.

Bunun bu durumda doğru, genel davada da doğru olduğuna inanıyorum.

Optimizasyon, eğer sebep olursa:

• daha az net kod
• önemli derecede daha fazla kod
• daha az güvenli kod
• boşa programcı zamanı

Sizin durumunuzda, programcının çok az zaman harcadığı görülüyor, kod çok karmaşık değildi (yorumunuza göre, takımdaki herkesin anlayabileceği bir tahmin) ve kod biraz daha ileride kanıtlanabilir şimdi anladım eğer şimdi anladım). Sadece küçük bir kötülük gibi geliyor. :)

Bu sorunun 5 yaşında olmasına şaşırdım ve henüz Knuth'un söylediklerinden birkaç cümle daha fazlasını kimse yayınlamadı. Ünlü alıntıyı çevreleyen iki paragraf bunu oldukça iyi açıklar. Alıntılanan yazıya " İfadelere Giden Yapısal Programlama " denir ve neredeyse 40 yaşına geldiğinde, hem artık var olmayan bir tartışma hem de bir yazılım hareketi ile ilgilidir ve birçok insanın asla programlamadığı dilleri programlama konusunda örnekler vardır. Ne söylediğinin şaşırtıcı derecede büyük bir kısmı hala geçerli.

İşte daha büyük bir alıntı (pdf'in 8. sayfasından, orijinalinin 268. sayfasından):

Örnek 2'den Örnek 2a'ya hızdaki gelişme sadece yaklaşık% 12'dir ve birçok kişi bu önemsiz olduğunu söyleyecektir. Günümüzün yazılım mühendislerinin çoğunun paylaştığı geleneksel bilgelik, küçük işletmelerdeki verimi görmezden gelmeyi gerektirir; ancak bunun, "optimize edilmiş" programlarını hata ayıklayamayan ya da bakımını yapamayan kuruşlu ve palavra aptal programcılar tarafından uygulandığını gördüğü suiistimallere aşırı tepki verdiğine inanıyorum. Yerleşik mühendislik disiplinlerinde, kolayca elde edilebilecek% 12'lik bir gelişme asla marjinal sayılmaz; ve aynı bakış açısının yazılım mühendisliğinde de geçerli olduğuna inanıyorum. Elbette tek seferlik bir işte böyle bir optimizasyon yapmaktan rahatsız olmazdım, ancak kaliteli programlar hazırlama meselesi olduğunda, kendimi bu tür etkinlikleri inkar eden araçlarla sınırlamak istemiyorum.

Hiç şüphe yok ki verimlilik kepçesi suistimale yol açıyor. Programcılar, programlarının kritik olmayan bölümlerinin hızını düşünerek veya endişelendirip çok fazla zaman harcarlar ve bu verimlilik denemeleri, hata ayıklama ve bakım dikkate alındığında gerçekten güçlü bir olumsuz etkiye sahiptir. Biz gereken küçük verimlilik unutun, zamanın yaklaşık% 97'sini ki: prematüre optimizasyon bütün kötülüklerin anasıdır.

Yine de, bu kritik% 3'teki fırsatlarımızı kaçırmamalıyız. İyi bir programcı, böyle bir nedenden ötürü rahatlama şansını yitirmeyecek, kritik koda dikkatlice bakmak akıllıca olacaktır; ancak bu kod tanımlandıktan sonra. Bir programın hangi bölümlerinin gerçekten kritik olduğu konusunda önceden karar vermek çoğu zaman bir hatadır, çünkü ölçme araçlarını kullanan programcıların evrensel deneyimi sezgisel tahminlerinin başarısız olduğu olmuştur.

Önceki sayfadan bir başka iyi bit:

Elbette kendi programlama stilim, son on yılda, zamanın trendine göre değişti (örneğin, artık o kadar zor değilim ve daha az kullanmaya başladım), ancak tarzımdaki en büyük değişiklik Bu iç döngü fenomenine. Şimdi, programımın ve veri yapımın (Örnek 1'den Örnek 2'deki değişiklikte olduğu gibi) değiştirilmesine çalışarak, kritik bir iç döngüdeki her operasyonda son derece sarı bir gözle bakıyorum, böylece işlemlerin bazıları elimine edilebilir. Bu yaklaşımın nedenleri şudur: a) iç döngü kısa olduğu için uzun sürmez; b) getirisi gerçektir; ve c) Programlarımın diğer bölümlerinde daha az verimli olabileceğimi ve bu nedenle daha okunaklı ve daha kolay yazılabilir ve hata ayıklanabilir.

Bu alıntıyı, kod ölçüsünü arttırmadan veya okunabilirliğinden ödün vermeksizin, performansının ölçülmemesine rağmen muhtemelen oldukça kolay bir şekilde daha hızlı bir şekilde yapılabilen hatalı kod veya kodu haklı çıkarmak için kullanıldığını sık sık gördüm.

Genel olarak, erken mikro optimizasyonların kötü bir fikir olabileceğini düşünüyorum. Bununla birlikte, makro optimizasyonlar (O (N ^ 2) yerine O (log N) algoritması seçmek gibi şeyler) genellikle faydalıdır ve bir O (N ^ 2) algoritması yazmak için zararlı olabilir; daha sonra O (log N) yaklaşımı lehine tamamen atın.

Kelimeleri olabilir : O (N ^ 2) algoritması basit ve yazılması kolaysa, çok yavaş olduğu ortaya çıkarsa daha sonra suçluluk duymadan fırlatabilirsiniz. Ancak, her iki algoritma da benzer şekilde karmaşıksa veya beklenen iş yükü zaten daha hızlı olana ihtiyacınız olduğunu bilecek kadar büyükse, erken optimizasyon yapmak, uzun vadede toplam iş yükünüzü azaltacak olan sağlam bir mühendislik kararıdır.

Bu nedenle, genel olarak, doğru yaklaşımın, kod yazmaya başlamadan önce seçeneklerinin ne olduğunu bulmak ve bilinçli olarak durumunuz için en iyi algoritmayı seçmek olduğunu düşünüyorum. En önemlisi, "erken optimizasyon tüm kötülüklerin köküdür" ifadesi cehalet için bahane değildir. Kariyer geliştiriciler, ortak işlemlerin maliyeti hakkında genel bir fikir sahibi olmalıdır; bilmeleri gerekir, örneğin,

• bu karakter dizileri rakamlardan daha pahalıya gelir
• dinamik dillerin statik olarak yazılmış dillerden çok daha yavaş olduğu
• dizi / vektör listelerinin bağlantılı listeler üzerindeki avantajları;
• bir karma tablo ne zaman, sıralı bir harita ne zaman ve bir yığın ne zaman kullanılır
• (mobil cihazlarla çalışıyorlarsa) "double" ve "int" masaüstlerinde benzer bir performansa sahiptir (FP daha hızlı olabilir) ancak "double" FPU'ları olmayan düşük kaliteli mobil cihazlarda yüzlerce kez daha yavaş olabilir;
• İnternet üzerinden veri aktarımı HDD erişiminden daha yavaş, HDD'ler RAM'den çok daha yavaş, RAM L1 önbellek ve kayıtlarından çok daha yavaş ve internet işlemleri süresiz olarak engelleyebilir (ve herhangi bir zamanda başarısız olabilir).

Ve geliştiriciler, iş için doğru araçları kolayca kullanabilmeleri için bir veri yapıları ve algoritmaları araç kutusuna aşina olmalıdır.

Bol miktarda bilgiye ve kişisel bir araç kutusuna sahip olmak neredeyse zahmetsizce optimize etmenizi sağlar. Gereksiz olabilecek bir optimizasyon içine çok fazla çaba koymak olduğunu kötülük (ve o tuzağa kereden fazla düşmekten itiraf). Ama optimizasyon listesini bir dizi yerine bir dizi / hashtable toplama veya depolama kadar kolay olduğunda sayılar çift [] yerine dize içinde [], o zaman neden olmasın? Burada Knuth'a katılmıyor olabilirim, emin değilim ama düşük seviye optimizasyondan bahsettiğini düşünüyorum, oysa yüksek seviye optimizasyondan bahsediyorum.

Unutmayın, bu alıntı aslen 1974'tür. 1974'te bilgisayarlar yavaştı ve hesaplama gücü pahalıydı; Bence bu Knuth'un buna karşı bastığı şeydi. “Performans hakkında endişelenme” demedi, çünkü 1974'te bu sadece çılgın bir konuşma olurdu. Knuth nasıl optimize edileceğini açıklıyordu ; Kısacası, kişi yalnızca darboğazlara odaklanmalı ve bunu yapmadan önce darboğazları bulmak için ölçümler yapmanız gerekir.

Ölçülecek bir program yazana kadar darboğazları bulamayacağınızı unutmayın; bu, ölçülecek bir şey olmadan önce bazı performans kararlarının alınması gerektiği anlamına gelir . Bazen yanlış karar alırsanız bu kararların değiştirilmesi zordur. Bu nedenle, ne kadar maliyetli olduğu konusunda genel bir fikre sahip olmak iyidir, bu nedenle herhangi bir zor veri bulunmadığında makul kararlar verebilirsiniz.

Optimize etmek için ne kadar erken ve performans konusunda ne kadar endişelenmek işe bağlı. Yalnızca birkaç kez çalıştıracağınız komut dosyaları yazarken, performans hakkında endişelenmek genellikle tam bir zaman kaybıdır. Ancak, Microsoft veya Oracle için çalışıyorsanız ve binlerce başka geliştiricinin binlerce farklı şekilde kullanacağı bir kitaplık üzerinde çalışıyorsanız , cehennemi optimize etmek için ödeme yapabilir; vakaları verimli kullanın. Buna rağmen, performans ihtiyacı her zaman okunabilirlik, bakım kolaylığı, şıklık, genişletilebilirlik vb. İhtiyaçlarla dengelenmelidir.

Şahsen, önceki bir başlıkta ele alındığı gibi, performans sorunlarına varacağınızı bildiğiniz durumlarda erken optimizasyonun kötü olduğuna inanmıyorum. Örneğin, düzenli olarak on milyonlarca kuruluş ile iş yaptığım yüzey modelleme ve analiz yazılımı yazıyorum. Tasarım aşamasında optimum performansı planlamak, zayıf bir tasarımın geç optimizasyonundan çok daha üstündür.

Dikkate alınması gereken bir diğer husus, başvurunuzun gelecekte nasıl ölçekleneceğidir. Kodunuzun uzun ömürlü olacağını düşünüyorsanız, tasarım aşamasında performansı optimize etmek de iyi bir fikirdir.

Tecrübelerime göre, gecikmeli optimizasyon yüksek fiyata düşük ödül sunar. Tasarım aşamasında, algoritma seçimi ve ince ayarlarla optimizasyon yapmak çok daha iyi. Kodunuzun nasıl çalıştığını anlamak için bir profilleyiciye bağlı olarak, yüksek performanslı bir kod elde etmenin harika bir yolu değildir, bunu önceden bilmeniz gerekir.

Aslında erken optimizasyonun optimizasyonun daha sık tüm kötülüklerin kaynağı olduğunu öğrendim.

İnsanlar yazılım yazdığında başlangıçta dengesizlik, sınırlı özellikler, kötü kullanılabilirlik ve kötü performans gibi problemler ortaya çıkar. Bunların hepsi genellikle yazılım olgunlaştığında sabitlenir.

Tüm bunlar, performans hariç. Kimse performansı önemsemiyor gibi görünüyor. Nedeni basit: bir yazılım çökerse, biri hatayı düzeltecek ve bir özellik eksikse, biri onu uygulayacak ve yapacak Kötü tasarım nedeniyle ve hiç kimse yazılımın tasarımına dokunmayacak. HİÇ.

Bochs'a bak. Cehennem kadar yavaş. Daha hızlı olacak mı? Belki, ama sadece yüzde birkaç aralığında. VMWare veya VBox ve hatta QEMU gibi sanallaştırma yazılımıyla karşılaştırılabilir performans hiçbir zaman elde edilemez. Çünkü tasarım yavaş!

Bir yazılımın sorunu yavaştırsa, o zaman ÇOK yavaş olduğundan ve bu da performansı çok fazla geliştirerek giderilebilir. % + 10, yavaş bir yazılımı hızlı bir şekilde yapmayacaktır. Ve genellikle sonraki optimizasyonlarla% 10'dan fazla kazanamayacaksınız.

Bu nedenle, performans yazılımınız için HERHANGİ bir öneme sahipse, bunu tasarlarken, "ah evet, yavaş ama daha sonra geliştirebiliriz" düşünmek yerine, bunu dikkate almalısınız. Çünkü yapamazsın!

Bunun sizin durumunuza tam olarak uymadığını biliyorum, ancak “Erken optimizasyon gerçekten tüm kötülüklerin kökeni midir?” Sorusunu yanıtlıyor. - net bir NO ile.

Her optimizasyon, herhangi bir özellik gibi, vb. Dikkatlice tasarlanmalı ve dikkatlice uygulanmalıdır. Bu, maliyet ve faydaların uygun bir değerlendirmesini içerir. Ölçülebilir bir performans kazancı sağlamadığında burada ve oradaki birkaç çevrimi kaydetmek için bir algoritmayı optimize etmeyin.

Örnek olarak: bir fonksiyonun performansını, muhtemelen bir kaç döngüden tasarruf ederek, satır içine alarak artırabilirsiniz, ancak aynı zamanda, muhtemelen, binlerce çevrime veya hatta binlerce tura mal olan TLB ve önbellek kaçırma şansını artırarak çalıştırılabilir boyutunuzu artırabilirsiniz. Tamamen performansı düşürecek çağrı işlemleri. Bunları anlamıyorsanız, "optimizasyonunuz" kötü sonuç verebilir.

Aptal optimizasyon "erken" optimizasyondan daha kötüdür, ancak ikisi de erken optimizasyondan daha iyidir.

PO ile iki problem vardır: birincisi, daha fazla özellik yazmak veya daha fazla hata düzeltmek için kullanılabilen, esastır olmayan işler için kullanılan geliştirme zamanı ve ikincisi, kodun verimli bir şekilde çalıştığı yanlış güvenlik duygusu. PO sık sık şişe boynu olmayacak olan kodun optimizasyonunu yaparken, kodun farkına varmaz. "Erken" bit, optimizasyonun bir problemin uygun ölçümler kullanılarak tanımlanmasından önce yapılması anlamına gelir.

Yani, temel olarak, evet, bu erken optimizasyona benziyor, ancak hatalar ortaya koymadıkça mutlaka geri adım atmayacağım - sonuçta, şimdi optimize edildi (!)

Mike Cohn'un “altın kaplama” olarak adlandırdığı şeyin kod olduğuna inanıyorum - yani güzel olabilecek ama gerekli olmayan şeylere zaman harcamak.

Buna karşı tavsiyede bulundu.

PS 'Gold-plating' çan ve ıslık gibi özel bir işlevsellik olabilir. Koda baktığınızda gereksiz optimizasyon, 'geleceğe dayanıklı' sınıflar vb.

Kodu anlamada herhangi bir sorun olmadığından, bu durum istisna olarak kabul edilebilir.

Ancak genel olarak optimizasyon daha az okunabilir ve daha az anlaşılabilir kodlara yol açar ve yalnızca gerektiğinde uygulanmalıdır. Basit bir örnek - sadece birkaç elementi sıralamanız gerektiğini biliyorsanız - BubbleSort kullanın. Ancak öğelerin artabileceğinden şüpheleniyorsanız ve ne kadar olduğunu bilmiyorsanız, QuickSort ile (örneğin) optimizasyon yapmak kötü değil, bir zorunluluktur. Ve bu programın tasarımında dikkate alınmalıdır.

Erken optimizasyon probleminin çoğunlukla mevcut kodu daha hızlı olacak şekilde yeniden yazarken ortaya çıktığını gördüm. Öncelikli olarak bazı sarılmış optimizasyonları yazmanın nasıl bir problem olduğunu görebiliyorum, fakat çoğunlukla kırılmamış olanı (bilindiği gibi) kırdığı şeyi düzeltmek için çirkin kafasını büyüten erken optimizasyon görüyorum.

Ve bunun en kötü örneği, standart bir kütüphaneden birinin özelliklerini yeniden uygulayan birini gördüğümde. Bu büyük bir kırmızı bayrak. Mesela bir keresinde dize manipülasyonu için özel rutinler uyguladığını gördüm çünkü yerleşik komutların çok yavaş olduğundan endişeliydi.

Bu, kodun anlaşılması daha zor (kötü) ve muhtemelen işe yaramayan (kötü) işe çok fazla zaman harcayan bir kodla sonuçlanır.

Farklı bir bakış açısına göre, çoğu programcının / geliştiricinin başarı için planlama yapmaması ve "prototip" in neredeyse her zaman Sürüm 1.0 olması benim deneyimim. Şık, seksi ve son derece işlevsel ön yüzün (temel olarak UI) yaygın kullanıcı kabulü ve coşku ile sonuçlandığı 4 ayrı orijinal üründe ilk elden deneyimim var. Bu ürünlerin her birinde, performans problemleri nispeten daha kısa sürede (1 ila 2 yıl), özellikle daha büyük, daha talepkar müşteriler, ürünü benimsemeye başladıkça sürünmeye başladı. Çok yakında performans, yeni özellik geliştirme yönetimin öncelikli listesine hakim olmasına rağmen, sorunlar listesine hakim oldu. Her sürüm, harika gibi görünen ancak performans sorunları nedeniyle neredeyse erişilemeyen yeni özellikler eklediğinden, müşteriler giderek daha fazla hüsrana uğradı.

Bu nedenle, "proto-tip" te çok az veya hiç kaygı duymayan çok temel tasarım ve uygulama hataları, ürünlerin (ve şirketlerin) uzun vadeli başarısı için büyük engeller haline geldi.

Müşteri demonuz dizüstü bilgisayarınızda XML DOM, SQL Express ve çok sayıda istemci tarafı önbelleğe alınmış verilerle harika görünebilir ve performans gösterebilir. Başarılı olursanız, üretim sistemi muhtemelen bir yanmaya neden olur.

1976'da karekök hesaplama veya büyük bir diziyi sıralamada en uygun yolları hala tartışıyorduk ve Don Knuth'un atasözü, sorunu çözmek yerine tasarım sürecinin başlarında bu tür düşük düzeyli bir rutini optimize etmeye odaklanmaya odaklandı. ve ardından yerelleştirilmiş kod bölgelerini optimize etmek.

Bir kişi atasözü verimli kod yazmamak (C ++, VB, T-SQL veya başka bir şekilde) veya veri deposunu uygun şekilde tasarlamamak veya net iş mimarisini düşünmemek için mazeret olarak tekrarlarsa, IMO sadece İşimizin gerçek doğasını çok sığ bir anlayış. ışın

Sanırım "prematüre" yi nasıl tanımladığına bağlı. Yazarken düşük seviyeli işlevselliği hızlı yapmak, doğası gereği kötü değildir. Bence bu teklifin yanlış anlaşılması. Bazen bu teklifin biraz daha kalifiye olabileceğini düşünüyorum. Ancak, m_pGladiator'ın okunabilirlik hakkındaki yorumlarını yankılandım.

Cevap, duruma bağlı. Verimliliğin, karmaşık veritabanı sorguları gibi belirli iş türleri için çok önemli olduğunu savunacağım. Diğer birçok durumda, bilgisayar zamanının çoğunu kullanıcı girişi için beklemektedir, bu nedenle çoğu kodu en iyi duruma getirmek en çok en az bir çaba kaybı ve en kötü üretkenliktir.

Bazı durumlarda verimlilik veya performans için tasarım yapabilirsiniz (algılanan veya gerçek) - uygun bir algoritma seçerek veya bir kullanıcı arayüzü tasarlayarak, örneğin arka planda belirli pahalı işlemlerin gerçekleşmesini sağlayabilirsiniz. Çoğu durumda, etkin noktaları belirlemek için profil oluşturma veya diğer işlemler size 10/90 avantaj sağlar.

Bunu tarif edebileceğim bir örnek, içinde yaklaşık 560 tablo bulunan bir dava davası yönetim sistemi için bir kez yaptığım veri modelidir. Normalleşmeye başladı (belli bir büyük 5 firmanın danışmanının belirttiği gibi 'güzel bir şekilde normalize edildi') ve içine yalnızca dört denormalize veri koymak zorunda kaldık:

• Bir arama ekranını desteklemek için bir materyalize görünüm

• Materyalize bir görünümle yapılamayan başka bir arama ekranını desteklemek için tetiklenen bir masa.

• Denormalize edilmiş bir raporlama tablosu (bu sadece bir veri ambarı projesi konserve edildiğinde bazı üretim raporları almamız gerektiğinden dolayı mevcuttu)

• Sistemdeki oldukça fazla sayıda farklı olayın en sonuncusunu aramak zorunda olan bir arabirim için tetiklenen bir tablo.

Bu (o sırada) Australasia'daki en büyük J2EE projesiydi - 100 yıldan fazla bir süredir geliştirici süresi - ve veritabanı şemasında bunlardan birine hiç ait olmayan 4 denormalize öğe vardı.

Erken optimizasyon TÜM kötülüklerin kökeni değil, orası kesin. Ancak bunun sakıncaları var:

• gelişim sırasında daha fazla zaman harcarsınız
• test etmek için daha fazla zaman harcıyorsunuz
• Aksi halde orada olmayan hataları düzeltmek için daha fazla zaman harcıyorsun

Erken optimizasyon yerine, daha iyi bir optimizasyon için gerçek bir ihtiyaç olup olmadığını görmek için erken görünürlük testleri yapılabilir.

“PMO” ya (kısmi alıntı) bağlı olanların çoğu, optimizasyonların ölçümlere dayanması gerektiğini ve ölçümlerin sonuna kadar gerçekleştirilemeyeceğini söylüyor.

Ayrıca, büyük sistemlerin geliştirilmesinden edindiğim deneyim, performans testinin en sonunda yapıldığı gibi, geliştirme tamamlanmaya yaklaştı.

Bu insanların önerilerini takip edersek, tüm sistemler dayanılmaz derecede yavaşlardı. Donanım ihtiyaçları da başlangıçta öngörülenden çok daha fazla olduğu için de pahalı olacaktı.

Geliştirme sürecinde düzenli aralıklarla performans testleri yapmayı uzun süredir savunuyorum: bu hem yeni kodun (daha önce hiçbirinin olmadığı yerde) hem de mevcut kodun durumunu gösterecektir.

• Yeni uygulanan kodun performansı, benzer kodunkiyle karşılaştırılabilir. Yeni kodun performansı için bir "his" zamanla oluşturulacak.
• Eğer mevcut kod birdenbire haywire giderse, ona bir şey olduğunu anlarsınız ve hemen sonra tüm sistemi etkilediğinde (çok) değil hemen inceleyebilirsiniz.

Başka bir evcil hayvan fikri, fonksiyon bloğu seviyesindeki enstrüman yazılımını kullanmaktır. Sistem yürütülürken, fonksiyon blokları için yürütme süreleri hakkında bilgi toplar. Bir sistem yükseltmesi gerçekleştirildiğinde, önceki sürümde olduğu gibi hangi fonksiyon bloklarının performans gösterdiği ve kötüleşenlerin tespit edilebildiği belirlenebilir. Bir yazılımın ekranında, performans verilerine yardım menüsünden erişilebilir.

Bu mükemmel parçaya PMO'nun ne anlama gelebileceği ya da ne anlama gelebileceği göz atın .