it-swarm.asia

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

Bugün bir meslektaşım, temelde Java Sınıfları yerel bir iş parçacığına dönüştürdüğü için ThreadLocalFormat adında bir sınıf gerçekleştirdi. Hızlı bir test yazdım ve saniyede 200.000 örnek oluşturabildiğimi hesapladım, ona "o kadar çok yerde" diye cevapladığı birçoğunu yarattığını sordum. O harika bir programcı ve takımdaki herkes çok yetenekli sonuçta ortaya çıkan kodu anlamakta sorun yaşamadık ama gerçekte ihtiyaç duyulmayan yerlerde optimizasyonun yapıldığı bir durumdu.Kodu benim isteğime göre destekledi.Ne düşünüyorsun? Bu bir "erken optimizasyon" vakası ve ne kadar kötü gerçekten mi?

224
Craig Day

Tüm alıntıyı akılda tutmak önemlidir:

Zamanın yaklaşık% 97'si gibi küçük verimlilikleri unutmalıyız: 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 optimize etmemelisiniz çünkü düşün bir performans kazancı elde edersiniz. Açık optimizasyonlar vardır (sıkı bir döngü içinde dize birleştirme yapmamak gibi), ancak ölçülene kadar önemsiz derecede net bir optimizasyon olmayan her şeyden kaçınılmalıdır.

"Erken optimizasyon" ile ilgili en büyük sorunlar, beklenmedik hatalar getirebilir ve büyük bir zaman kaybı olabilir.

333
Scott Dorman

Erken mikro optimizasyonlar tüm kötülüklerin köküdür, çü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ı, bileşen ve katmanlanma şekli)
  • Veri akışı optimizasyonları (uygulamanın içinde ve dışında)

Orta geliştirme döngüsü optimizasyonlarından bazıları:

  • Veri yapıları, daha iyi performansa veya gerekirse ek yükü azaltan yeni veri yapılarını tanıtın
  • 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 sıcak noktalarını bulma (optimize edilmesi gereken sıkı döngüler)
  • Kodun hesaplama bölümlerinin profil tabanlı optimizasyonları
  • Mikro optimizasyonlar artık uygulama bağlamında yapıldığı ve etkilerinin doğru ölçülebildiği için yapılabilir.

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, mimariyi olumsuz etkileyebildikleri, başlangıçtaki üretkenliği olumsuz etkileyebileceği, alakasız performans açısından akıllıca veya hatta farklı çevre koşulları nedeniyle gelişimin sonunda zararlı bir etkiye sahiptir.

Performans endişe verici ise (ve her zaman olmalı) daima düşünün büyük. Performans daha büyük bir resimdir ve şu gibi şeylerle ilgili değildir: int veya uzun? Aşağıdan Yukarı yerine performansla çalışırken Yukarıdan Aşağı seçeneğine gidin.

112
Pop Catalin

optimizasyon ilk ölçüm olmadan neredeyse her zaman erken.

Bu durumda bunun doğru ve genel durumda da doğru olduğuna inanıyorum.

54
Jeff Atwood

Neden olursa optimizasyon "kötüdür":

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

Sizin durumunuzda, biraz programcı zaman geçirmiş gibi görünüyor, kod çok karmaşık değildi (yorumunuzdan takımdaki herkesin anlayabileceği bir tahmin) ve kod biraz daha gelecekteki bir kanıt (varlık Eğer açıklamayı anladıysam şimdi güvenli iplik). Biraz kötülük gibi geliyor. :)

44
John Mulder

Bu sorunun 5 yaşında olmasına şaşırdım ve henüz hiç kimse Knuth'un söylemek zorunda olduğu şeylerden birkaç cümle daha fazla açıklama yapmadı. Ünlü alıntıyı çevreleyen birkaç paragraf bunu oldukça iyi açıklıyor. Alıntılanan kağıda " İfadelere Git ile Yapısal Programlama " denir ve yaklaşık 40 yaşındayken, artık var olmayan bir tartışma ve yazılım hareketiyle ilgilidir ve birçok insanın hiç duymadığı programlama dilleri, şaşırtıcı derecede büyük bir kısmı hala geçerli.

Daha büyük bir alıntı (pdf'in 8. sayfasından, orijinalinde sayfa 268'den):

Örnek 2'den Örnek 2a'ya olan hızdaki iyileşme sadece yaklaşık% 12'dir ve birçok insan bu önemsiz olanı telaffuz edecektir. Günümüzün yazılım mühendislerinin birçoğu tarafından paylaşılan geleneksel bilgelik, küçük işletmelerde verimliliği görmezden gelme çağrısı yapıyor; ancak bunun "optimize edilmiş" programlarında hata ayıklayamayacak veya sürdüremeyen kuruş bilge ve pound-aptal programcılar tarafından uygulandığını gördükleri istismarlara aşırı tepki olduğuna inanıyorum. Yerleşik mühendislik disiplinlerinde, kolayca elde edilen% 12'lik bir iyileşme asla marjinal kabul edilmez; yazılım mühendisliğinde de aynı bakış açısının geçerli olması gerektiğine inanıyorum. Tabii ki tek seferlik bir işte bu tür optimizasyonlar yapmaktan rahatsız olmazdım, ancak bu kaliteli programlar hazırlamakla ilgili bir sorun olduğunda, kendimi beni bu tür verimlilikleri reddeden araçlarla sınırlamak istemiyorum.

Hiç şüphe yok ki, verimlilik kâse kötüye kullanıma yol açar. Programcılar, programlarının kritik olmayan bölümlerinin hızını düşünmek veya bunlardan endişe etmek için çok fazla zaman harcarlar ve bu verimlilik girişimlerinin hata ayıklama ve bakım dikkate alındığında aslında güçlü bir olumsuz etkisi vardır. Biz küçük verimlilikleri unutmalıyız, zamanın yaklaşık% 97'sini söylüyoruz: erken optimizasyon tüm kötülüğün köküdür.

Yine de bu kritik% 3'teki fırsatlarımızı kaçırmamalıyız. İyi bir programcı böyle bir akıl yürütme ile gönül rahatlığına uğramayacak, eleştirel koda dikkatle bakacaktır; ancak bu kod tanımlandıktan sonra. Bir programın hangi bölümlerinin gerçekten kritik olduğu konusunda önsel yargıda bulunmak çoğu zaman bir hatadır, çünkü ölçüm araçlarını kullanan programcıların evrensel deneyimi sezgisel tahminlerinin başarısız olmasıdır.

Önceki sayfadan bir başka iyi şey:

Kendi programlama tarzım elbette son on yılda, zamanların eğilimlerine göre değişti (örneğin, artık çok zor değilim ve daha az git kullanıyorum), ancak tarzımdaki büyük değişiklik nedeniyle bu iç döngü olgusuna. Şimdi kritik bir iç döngüdeki her operasyonda son derece sarılıklı bir gözle bakıyorum, programımı ve veri yapımı (Örnek 1'den Örnek 2'ye geçişte olduğu gibi) değiştirmek için bazı işlemler ortadan kaldırılabilir. Bu yaklaşımın nedenleri: a) iç döngü kısa olduğu için uzun sürmez; b) getirinin gerçek olması; ve c) Programlarımın diğer bölümlerinde daha az verimli olmayı göze alabilirim, bu nedenle daha okunabilir ve daha kolay yazılır ve hata ayıklanır.

39
Michael Shaw

Bu alıntıyı, performansı ölçülmemiş olsa da, kod boyutunu artırmadan veya okunabilirliğinden ödün vermeden muhtemelen oldukça hızlı bir şekilde yapılabilen bariz kötü kod veya kodu haklı çıkarmak için sıklıkla kullandı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 değerlidir ve O (N ^ 2) algoritması yazmanın israfı olabileceğinden erken yapılması gerekir. sonra tamamen O (log N) yaklaşımı lehine atın.

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

Bu nedenle, genel olarak, doğru yaklaşımın kod yazmaya başlamadan önce seçeneklerinizin 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 bir mazeret değildir. Kariyer geliştiricilerin ortak operasyonların maliyeti hakkında genel bir fikri olmalıdır; örneğin bilmeliler

  • dizelerin rakamlardan daha pahalı olduğunu
  • dinamik diller, statik olarak yazılmış dillerden çok daha yavaştır
  • dizi/vektör listelerinin bağlantılı listelere göre avantajları veya tam tersi
  • bir hashtable ne zaman, sıralı bir harita ne zaman ve bir yığın ne zaman kullanılır
  • (mobil cihazlarla çalışırlarsa) "çift" ve "int" masaüstlerinde benzer performansa sahiptirler (FP daha da hızlı olabilir), ancak "double", FPU'ları olmayan düşük kaliteli mobil cihazlarda yüz kat daha yavaş olabilir;
  • i̇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ştır ve internet işlemleri süresiz olarak engellenebilir (ve her zaman 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.

Çok fazla bilgiye ve kişisel bir araç kutusuna sahip olmak neredeyse zahmetsizce optimize etmenizi sağlar. Gereksiz olabilecek bir optimizasyona çok çaba sarf etmek is kötü (ve bu tuzağa birden fazla kez düştüğümü itiraf ediyorum). Ancak optimizasyon bir dizi yerine bir küme/hashtable seçmek veya dizi [] yerine çift [] içinde sayı listesini saklamak kadar kolay olduğunda neden olmasın? Burada Knuth ile aynı fikirde değilim, emin değilim, ama sanırım düşük seviyeli optimizasyondan bahsediyor, oysa yüksek seviyeli optimizasyondan bahsediyorum.

Unutmayın, bu alıntı aslında 1974'ten kalmadır. 1974'te bilgisayarlar yavaştı ve hesaplama gücü pahalıydı, bu da bazı geliştiricilere satır satır aşırı optimizasyon eğilimi verdi. Bence Knuth buna karşı çıkıyordu. "Performans hakkında hiç endişelenme" demiyordu, çünkü 1974'te bu sadece çılgınca bir konuşma olurdu. Knuth, optimize etmek için nasıl açıklıyordu; Kısacası, sadece darboğazlara odaklanmalı ve bunu yapmadan önce darboğazları bulmak için ölçümler yapmalısınız.

Ölçmek için bir program yazana kadar darboğazları bulamayacağınızı unutmayın, bu da bazı performans kararlarının zorunl ölçülecek bir şeyden önce alınacağı anlamına gelir. Bazen yanlış karar verirseniz bu kararların değiştirilmesi zordur. Bu nedenle, sabit bir veri olmadığında makul kararlar verebilmeniz için işlerin maliyeti hakkında genel bir fikre sahip olmak iyidir.

Optimize etmek için ne kadar erken ve performans konusunda ne kadar endişelenmeniz işe bağlıdır. Yalnızca birkaç kez çalıştıracağınız komut dosyaları yazarken, performanstan endişe etmek genellikle tam bir zaman kaybıdır. Ancak Microsoft veya Oracle için çalışıyorsanız ve binlerce başka geliştirici binlerce farklı şekilde kullanacak bir kütüphane üzerinde çalışıyorsanız, cehennemi optimize etmek için ödeme yapabilir, bu yüzden çeşitli kullanım durumlarını etkin bir şekilde ele alabilmenizi sağlar. Yine de, performans ihtiyacı, okunabilirlik, sürdürülebilirlik, zarafet, genişletilebilirlik vb. İhtiyaçlarla her zaman dengelenmelidir.

21
Qwertie

Şahsen, bir önceki iş parçacığı kapsamında olduğu gibi, performans sorunlarını vuracağınızı bildiğiniz durumlarda erken optimizasyonun kötü olduğuna inanmıyorum. Örneğin, düzenli olarak on milyonlarca varlıkla uğraştığım yüzey modelleme ve analiz yazılımı yazıyorum. Tasarım aşamasında optimum performans için planlama, zayıf bir tasarımın geç optimizasyonundan çok daha üstündür.

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

Deneyimlerime göre, geç optimizasyon yüksek bir fiyata yetersiz ödüller sağlar. Algoritma seçimi ve ince ayar yoluyla tasarım aşamasında optimizasyon yapmak çok daha iyi. Kodunuzun nasıl çalıştığını anlamak için bir profil oluşturucuya bağlı olarak, yüksek performanslı kod almanın harika bir yolu olmadığını, bunu önceden bilmeniz gerekir.

14
SmacL

Aslında erken optimizasyon dışı olmanın daha çok tüm kötülüklerin kökü olduğunu öğrendim.

İnsanlar yazılım yazdıklarında başlangıçta kararsızlık, sınırlı özellikler, kötü kullanılabilirlik ve kötü performans gibi problemler olacaktır. Yazılım olgunlaştığında bunların tümü genellikle sabitlenir.

Performans dışında bunların hepsi. Kimse performansı önemsemiyor gibi görünüyor. Nedeni basit: Bir yazılım çökerse, biri hatayı düzeltir ve işte bu, eğer bir özellik eksikse, birisi onu uygular ve yapar, yazılım kötü performansa sahipse, çoğu durumda eksik mikrooptimizasyondan kaynaklanmaz, ancak Kötü tasarım nedeniyle ve hiç kimse yazılımın tasarımına dokunmayacak. HİÇ.

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

Bir yazılımın sorunu yavaş olması, o zaman ÇOK yavaş olması ve bu sadece performansı çok sayıda artırarak düzeltilebilir. % + 10 yavaş bir yazılımı hızlı yapmaz. Ve genellikle daha sonraki optimizasyonlarla% 10'dan fazla elde edemezsiniz.

Dolayısıyla, performans yazılımınız için HERHANGİ önemliyse, "oh evet, yavaş, ama daha sonra geliştirebiliriz" diye düşünmek yerine, bunu baştan tasarlarken, tasarlarken dikkate almalısınız. Çünkü yapamazsın!

Bunun özel durumunuza gerçekten uymadığını biliyorum, ancak "Erken optimizasyon gerçekten tüm kötülüğün kökü mü?" - açık bir NO ile.

Herhangi bir özellik gibi her optimizasyon dikkatle tasarlanmalı ve dikkatle uygulanmalıdır. Bu, maliyet ve faydaların doğru değerlendirilmesini de içerir. Ölçülebilir bir performans kazancı oluşturmadığında, burada ve orada birkaç döngü kaydetmek için bir algoritmayı optimize etmeyin.

Örnek olarak: bir işlevin performansını satır içine alarak, muhtemelen birkaç döngüyü kaydederek artırabilirsiniz, ancak aynı zamanda yürütülebilir dosyalarınızın boyutunu da artırabilir, TLB ve önbellek özledim şansını artırarak binlerce döngüye hatta performansı tamamen öldürecek çağrı işlemleri. Bunları anlamadıysanız, "optimizasyonunuz" kötüye gidebilir.

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

10
Timo

PO ile ilgili iki sorun vardır: birincisi, daha fazla özellik yazmak veya daha fazla hatayı düzeltmek için kullanılabilecek temel olmayan işler için kullanılan geliştirme süresi ve ikincisi, kodun verimli bir şekilde çalıştığı yanlış güvenlik duygusu. PO genellikle, şişe boynu olmayacak olan kodu optimize ederken, kodun farkına varmamayı da içerir. "Erken" bit, uygun ölçümler kullanılarak bir sorun tanımlanmadan önce optimizasyonun yapıldığı anlamına gelir.

Yani temelde, evet, bu erken optimizasyon gibi geliyor, ancak böcek tanıtmadıkça mutlaka geri vermeyeceğim - sonuçta, şimdi optimize edildi (!)

6
harriyott

Farklı bir bakış açısından, çoğu programcı/geliştiricinin başarı için plan yapmadığı ve "prototip" neredeyse her zaman Sürüm 1.0 haline geldiğidir. Şık, seksi ve son derece işlevsel ön ucun (temelde UI) geniş kullanıcı kabulü ve coşkusu ile sonuçlandığı 4 ayrı orijinal ürünle ilk elden deneyimim var. Bu ürünlerin her birinde, özellikle daha büyük, daha talepkar müşteriler, ürünü benimsemeye başladıkça, performans sorunları nispeten kısa sürede (1-2 yıl) sürünmeye başladı. Yeni özellik geliştirme, yönetimin öncelik listesine hakim olmasına rağmen, performans çok yakında performansa hakim oldu. Her sürüm, kulağa harika gelen ancak performans sorunları nedeniyle neredeyse erişilemeyen yeni özellikler ekledikçe müşteriler giderek daha fazla sinirlendi.

Bu nedenle, "proto-tipi" ile çok az ilgilenen veya hiç ilgisi olmayan çok temel tasarım ve uygulama kusurları, ürünlerin (ve şirketlerin) uzun vadeli başarısı için büyük engeller haline geldi.

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

1976'da hala bir kare kökü hesaplamanın veya büyük bir diziyi sıralamanın en uygun yollarını tartışıyorduk ve Don Knuth'un atasözü, sorunu çözmek yerine bu tür düşük seviyeli rutini tasarım sürecinin erken aşamalarında optimize etmeye odaklanma hatasına yönlendirildi. ve daha sonra yerelleştirilmiş kod bölgelerinin optimize edilmesi.

Verimli kod (C++, VB, T-SQL veya başka bir şekilde) yazmama veya veri deposunu düzgün bir şekilde tasarlamama veya net çalışma mimarisini düşünmeme için bir mazeret olarak tekrarlandığında, IMO sadece bir işimizin gerçek doğası hakkında çok sığ bir anlayış. ışın

3
Ray

Kodu anlamada bir sorun olmadığından, bu durum bir istisna olarak değerlendirilebilir.

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

3
m_pGladiator

Mike Cohn'un kodu 'altın kaplama' olarak adlandırdığı şeye inanıyorum - yani Nice olabilecek ancak gerekli olmayan şeylere zaman harcamak.

Buna karşı tavsiyede bulundu.

Not; 'Altın kaplama' özel olarak çan ve ıslık bir işlevsellik olabilir. Koda baktığınızda, gereksiz optimizasyon, 'geleceğe yönelik' sınıflar vb.

3
Ilya Kochetov

Erken optimizasyon ile ilgili sorun çoğunlukla daha hızlı olması için mevcut kodu yeniden yazarken meydana geldiğini buldum. İlk etapta bazı kıvrımlı optimizasyonun yazılmasının nasıl bir sorun olabileceğini görebiliyorum, ama çoğunlukla kırılmayan şeyleri düzeltmede çirkin kafasını yetiştiren erken optimizasyon görüyorum.

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

Bu, anlaşılması daha zor olan kod (kötü) ile sonuçlanır ve muhtemelen işe yaramayan (kötü) iş üzerinde çok fazla zaman yakar.

3
jhocking

"PMO" ya (kısmi alıntı) bağlı olanların çoğu, optimizasyonların ölçümlere dayalı olması gerektiğini ve ölçümlerin en sonuna kadar yapılamayacağını söylüyor.

Büyük sistem geliştirme deneyimim de, performans testinin en sonunda, geliştirme tamamlanmaya yaklaştıkça yapıldığı yönünde.

Bu insanların "tavsiyelerini" takip edecek olsaydık, tüm sistemler dayanılmaz derecede yavaş olurdu. Onlar da pahalı olurdu çünkü donanım ihtiyaçları başlangıçta öngörülenden çok daha fazla.

Uzun geliştirme sürecinde düzenli aralıklarla performans testleri yapmayı savundum: hem yeni kodun varlığını (daha önce hiçbir yerde yoktu) hem de mevcut kodun durumunu gösterecektir.

  • Yeni uygulanan kodun performansı mevcut, benzer kodun performansı ile karşılaştırılabilir. Zaman içinde yeni kodun performansı için bir "his" oluşturulacaktır.
  • Mevcut kod aniden haywire'a giderse, bir şeyin başına geldiğini anlarsınız ve daha sonra tüm sistemi etkilediğinde (çok) değil, hemen araştırabilirsiniz.

Diğer bir evcil hayvan fikri, yazılımları fonksiyon bloğu düzeyinde 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 işlev bloklarının performans gösterdiğini ve kötüleşenleri belirleyebilir. Bir yazılımın ekranında performans verilerine yardım menüsünden erişilebilir.

Kontrol edin this PMO'nun ne anlama gelebileceği veya hiçbir anlamı olmayabileceği konusunda mükemmel bir parça.

1
Olof Forshell

Sanırım "erken" nasıl tanımladığınıza bağlı. Yazarken düşük seviyeli işlevselliği hızlı hale getirmek doğal olarak kötü değildir. Bence bu teklifin yanlış anlaşılması. Bazen bu teklifin daha fazla yeterlilikle yapılabileceğini düşünüyorum. Yine de m_pGladiator'ın okunabilirlik hakkındaki yorumlarını yankılarım.

1
Dominic Rodger

Cevap, duruma bağlı. Verimliliğin karmaşık veritabanı sorguları gibi belirli iş türleri için önemli olduğunu iddia edeceğim. Diğer birçok durumda bilgisayar zamanının çoğunu kullanıcı girdisini beklemek için harcıyor, bu nedenle çoğu kodu optimize etmek en iyi ihtimalle çaba kaybı ve en kötü verimsiz.

Bazı durumlarda, verimlilik veya performans (algılanan veya gerçek) için tasarlayabilirsiniz - uygun bir algoritma seçerek veya bir kullanıcı arabirimi tasarlayarak, örneğin arka planda bazı pahalı işlemler gerçekleşir. Çoğu durumda, sıcak noktaları belirlemek için profil oluşturma veya diğer işlemler size 10/90 avantaj sağlayacaktır.

Bunu tarif edebileceğim bir örnek, bir zamanlar içinde yaklaşık 560 tablo bulunan bir mahkeme dava yönetim sistemi için yaptığım veri modelidir. Normalleşmeye başladı (belirli bir büyük 5 firmasının danışmanı olarak 'güzelce normalize') ve sadece dört adet denormalize veri koymak zorunda kaldık:

  • Arama ekranını desteklemek için tek bir materyal görünümü

  • Bir görünümle gerçekleştirilemeyen başka bir arama ekranını desteklemek için tetikleyici tarafından korunan bir tablo.

  • Denormalize edilmiş bir raporlama tablosu (bu sadece mevcuttu çünkü bir veri ambarı projesi hazır olduğunda bazı verimlilik raporları almak zorunda kaldık)

  • Sistemdeki çok sayıda farklı olayın en sonlarını aramak zorunda olan bir arabirim için tetikleyici tarafından korunan bir tablo.

Bu, (o zaman) Avustralya'daki en büyük J2EE projesiydi - 100 yıldan fazla geliştirici zamanı - ve veritabanı şemasında biri gerçekten oraya ait olmayan 4 denormalize ürün vardı.

Erken optimizasyon TÜM kötülüğün kökü değildir, bu kesin. Ancak bunun dezavantajları vardır:

  • geliştirme sırasında daha fazla zaman harcıyorsun
  • test etmek için daha fazla zaman harcıyorsun
  • aksi takdirde orada olmayacak hataları düzeltmek için daha fazla zaman harcarsınız

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

1
Herr_Alien