it-swarm.asia

Kodlama yaparken mikro optimizasyon önemli mi?

Geçenlerde Stack Overflow'da isset () 'in neden strlen () in PHP olduğunu öğrenmek için bir soru sordum. Bu, okunabilir kodun önemi ve koddaki mikro saniyelerin performans iyileştirmelerinin bile göz önünde bulundurulmaya değer olup olmadığı sorusunu gündeme getirdi.

Babam emekli bir programcı ve ona cevapları gösterdim. Bir kodlayıcı mikro düzeyde bile kodlarındaki performansı dikkate almazsa, iyi programcılar olmadıklarından kesinlikle emindi.

Emin değilim - belki de hesaplama gücündeki artış, artık bu tür mikro performans iyileştirmelerini dikkate almak zorunda olmadığımız anlamına mı geliyor? Belki de bu tür bir düşünce, gerçek dil kodunu yazan kişilere bağlıdır? (PHP).

Çevresel faktörler önemli olabilir - İnternet dünya enerjisinin% 10'unu tüketir. Milyonlarca web sitesinde trilyonlarca kez çoğaltıldığında birkaç mikro saniyelik kodun ne kadar boşa harcadığını merak ediyorum?

Tercihen programlama hakkındaki gerçeklere dayanarak cevapları bilmek istiyorum.

Kodlama sırasında mikro optimizasyon önemli mi?

Herkese teşekkürler 25 cevaplı kişisel özetim.

Bazen mikro optimizasyonlar hakkında gerçekten endişelenmemiz gerekir, ancak sadece çok nadir durumlarda. Çoğu durumda güvenilirlik ve okunabilirlik çok daha önemlidir. Bununla birlikte, zaman zaman mikro-optimizasyon düşünmek acı vermez. Temel bir anlayış, kodlama sırasında bariz kötü seçimler yapmamıza yardımcı olabilir.

if (expensiveFunction() || counter < X)

Olmalı

if (counter < X || expensiveFunction())

( @ zidarsk8'den örnek ) Bu ucuz bir işlev olabilir ve bu nedenle kodun değiştirilmesi mikro optimizasyon olacaktır. Ancak, temel bir anlayışla, bunu yapmak zorunda kalmazsınız, çünkü ilk etapta doğru yazarsınız.

181
Boz

Babana hem katılıyorum hem de katılmıyorum. Performans erken düşünülmeli, ancak mikro-optimizasyon sadece erken düşünülmelidir zamanın yüksek bir yüzdesinin küçük harcanacağını biliyorsanız Kodun CPU'ya bağlı bölümleri.

Mikro optimizasyon ile ilgili problem, genellikle programların gerçekten gerekenden daha fazla zaman harcadığına dair herhangi bir kavram olmadan yapılmasıdır.

Bu bilgi, performans ayarlaması yapma deneyiminden gelir, bu örnekte olduğu gibi , açıkça verimsizliği olmayan görünüşte basit bir program, 43 kat daha hızlı olana kadar bir dizi tanı ve hızlandırma adımından geçer. başlangıcından daha fazla.

Gösterdiği şey, problemlerin nerede olacağını gerçekten tahmin edemeyeceğiniz veya sezemeyeceğinizdir. Benim durumumda rasgele duraklatma olan tanı yaparsanız, önemli bir zaman diliminden sorumlu kod satırları tercihli olarak ortaya çıkar. Bunlara bakarsanız, yedek kod bulabilir ve böylece kabaca bu kesir ile toplam süreyi azaltabilirsiniz.

Düzeltmediğiniz diğer şeyler hala daha önce olduğu kadar zaman alır, ancak toplam süre azaldığından, bu şeyler artık daha büyük bir kesir alır, bu yüzden tekrar yaparsanız, bu kesir de ortadan kaldırılabilir. Bunu birden çok yinelemede yapmaya devam ederseniz, muazzam hızlanma, mikro optimizasyonu .

Bu tür bir deneyimden sonra, yeni programlama sorunlarına yaklaştığınızda, başlangıçta bu tür verimsizliklere yol açan tasarım yaklaşımlarını fark edersiniz. Deneyimlerime göre, veri yapısı, normalleştirilmemiş veri yapısı, bildirimlere büyük güven, bu tür şeylerin aşırı tasarımından geliyor.

90
Mike Dunlavey

Mikro optimizasyon sadece sayılar söylerse önemlidir.

Performans, istemci veya kullanıcı için önemliyse, karşı karşıya olduğunuz gereksinimlerin performans verileri için bazı özellikleri olmalıdır. Yazılım geliştirirken, sisteminizin performansını bu gereksinimlere göre test etmelisiniz. Performans gereksinimlerini karşılamıyorsanız, kod tabanınızı profilinize eklemeniz ve performans gereksinimlerine ulaşmak için gereken şekilde optimize etmeniz gerekir. Gerekli minimum performansa girdikten sonra, özellikle kodun okunabilirliğini ve sürdürülebilirliğini artık tehlikeye atacaksanız, sistemden daha fazla performans sıkıştırmanıza gerek yoktur (benim deneyimime göre, son derece optimize edilmiş kod daha az okunabilir ve korunabilir, ancak her zaman değil). Sistemin diğer kalite özelliklerini bozmadan ek performans kazanımları elde edebiliyorsanız, bunu dikkate alabilirsiniz.

Bununla birlikte, performansın en önemli olduğu durumlar vardır. Ben esas olarak gerçek zamanlı sistemleri ve gömülü sistemleri düşünüyorum. Gerçek zamanlı sistemlerde, işlem sırasının değiştirilmesi, düzgün işlem için gerekli olan son teslim tarihlerini karşılama üzerinde büyük bir etkiye sahip olabilir, hatta hesaplamaların sonuçlarını bile etkileyebilir. Gömülü sistemlerde, tipik olarak sınırlı bellek, CPU gücü ve gücünüz vardır (pil gücünde olduğu gibi), bu nedenle ikili dosyalarınızın boyutunu azaltmanız ve sistem ömrünü en üst düzeye çıkarmak için hesaplama sayısını azaltmanız gerekir.

120
Thomas Owens

Herkes optimizasyon hakkında soru sorduğunda, alıntıMichael A. Jackson

Program Optimizasyonunun İlk Kuralı: Yapmayın.

İkinci Program Optimizasyonu Kuralı (yalnızca uzmanlar için!): Yapmayın henüz.

Vikipedi'den alıntı İngiliz İngilizcesi için düzeltildi. * 8' )

İkinci kuralda örtük profil kodunuz ve sadece zaman harcamak fark yaratacak şeyleri optimize etmek.

Meclis'te programlama yaparken babanızın iddiası doğruydu. Ancak bu, bu günlerde çoğu insanın programından çok daha yakın. Bugün bile çalışıyor kendinizi (profil oluşturmadan) kodunuzu çalıştırmanıza neden olabilir daha yavaş daha yaygın bir yol yapmış olmanızdan daha fazla ortak yol modern JIT derleyiciler tarafından optimize edilmesi daha olasıdır.

C'de bile, bir kod bölümünü derleyiciden daha iyi nasıl optimize edeceğinizi öğrenmek için optimizasyonda oldukça iyi olmalısınız.

Ulrich Drepper'ın mükemmel makalesinde konuştuklarının çoğunu bilmiyorsanız Her Programcının Bellek Hakkında Bilmesi Gerekenler, o zaman muhtemelen bir eziksiniz kendini optimize etmeye çalışıyor. Ancak makalelerin aksine (bu aslında David Goldberg'in eşit derecede fantastik bir saygıdır Her Bilgisayar Bilimcisinin Kayan Nokta Aritmetiği Hakkında Bilmesi Gerekenler) anlayış iyi bir programcı olmanızı engellemez, sadece farklı bir programcıdır.

isset() vs. strlen() inç PHP

PHP bilmiyorum, bu yüzden isset() ne yapmak gerçekten açık değildir. Ben bağlamdan çıkarım yapabilir, ama bu benzer şekilde acemi PHP programcılar ve hatta daha deneyimli programcılar çift almak için neden olabilir belirsiz olacaktır anlamına gelir. Bu tür Bu tür deyimsiz bakımın kabusu olabilecek bir dilin kullanılması.

Sadece bu değil, aynı zamanda isset() 'in her zaman daha verimli olacağının garantisi yoktur, çünkü şimdi daha verimli olduğu için. Bir optimizasyon şimdi gelecek yıl veya 10 yıl içinde bir optimizasyon olmayabilir. İşlemciler, sistemler, derleyiciler zamanla gelişir ve değişir. PHP'nin strlen() performansı bir sorunsa, PHP gelecekte değiştirilebilir), o zaman kodu optimize etmek için tüm isset () optimizasyonlarının kaldırılması gerekebilir bir kez daha.

Her optimizasyon bir gelecek olma potansiyeline sahiptir anti-optimizasyon, bu nedenle minimumda tutulması için olası bir kod kokusu olarak düşünülmelidir.

Kişisel deneyimlerden bir örnek

Böyle bir anti-optimizasyon örneği olarak, bir zamanlar if x==0 z=0 else z=x*y Koduyla dolu büyük bir kod tabanını sanitize etmek zorunda kaldım çünkü birisi kayan noktanın çarptığı varsayımını yapmıştı her zaman bir şubeden daha pahalı olacaktı. Orijinal hedef mimaride bu optimizasyon, kodun daha büyük bir sıraya göre daha hızlı çalışmasını sağladı, ancak zaman değişti.

Bu kodu son derece pipeline edilmiş daha modern bir CPU'da kullanmaya çalıştığımızda performans korkunç derecede kötüydü - bu ifadelerin her biri bir boru hattının yıkanmasına neden oluyor. Tüm bu kod satırlarını sadece z=x*y Olarak basitleştirmek, programın yeni mimari üzerinde daha büyük bir sıraya daha hızlı çalışmasını sağladı ve anti-optimizasyon kaybettiği performansı geri getirdi.

Bugün için genellikle optimize etmemiz gereken problemler çok 20 veya 10 yıl önce optimize etmemiz gereken sorunlardan farklıdır.

Daha sonra saat döngüsü başına en fazla işi yapmaktan endişe duyuyoruz, şimdi boru hattı yıkamaları, şube yanlış tahminleri ve CPU düzeyinde önbellek özlemleri hakkında endişelenme olasılığımız daha yüksek, ancak kilitler ve süreçler arası iletişim çok = çok işlemli ve çok işlemcili mimarilere geçtiğimiz için daha önemli. Drepper'ın makalesi bu sorunların çoğunun anlaşılmasına gerçekten yardımcı olabilir.

103
Mark Booth
  1. Temiz, özlü, basit ve açıklayıcı bir kod yazın.
  2. Darboğazları belirlemek için performans testleri yapın.
  3. Kritik bölümleri optimize edin.

Genel bir kural olarak: Kodunuzun% 95'i zamanın% 5'ini çalıştırır. Kodunuzu profil/karşılaştırma yapmadan ve% 5'inin% 95'inin çalıştığını görmeden önce optimize etmenin bir anlamı yoktur.

Her salak mikro optimizasyon yapabilir ve iyi bir derleyici/çalışma zamanı bunu sizin için yapar.
İyi kodu optimize etmek önemsizdir. Optimize edilmiş kod yazmak ve bundan sonra iyi yapmaya çalışmak en iyisi sıkıcı ve en kötüsü sürdürülemez.

ciddi olarak performansla ilgileniyorsanız, kritik performans kodu için PHP kullanmayın. Darboğazları bulun ve C uzantılarıyla yeniden yazın. PHP kodunuzu gizleme noktasının ötesinde mikro optimize etmek bile sizi neredeyse o kadar hızlandırmaz.

Kişisel olarak, programlamaya başladığımda mikro optimizasyon yapmayı çok sevdim. Çünkü ortada. Çünkü seni çabucak ödüllendiriyor. Çünkü önemli kararlar almak zorunda değilsiniz. Bu erteleme mükemmel anlamına gelir. Yazılım geliştirmenin gerçekten önemli kısımlarından kaçmanızı sağlar: Ölçeklenebilir, esnek, genişletilebilir, sağlam sistemlerin tasarımı.

84
back2dos

Babanla aynı fikirdeyim: "Eğer bir kodlayıcı mikro düzeyde bile kodlarındaki performansı dikkate almazsa, onlar iyi bir programcı değildir." Anahtar, "performansı dikkate almak" tır. Bu, "her adımda mikro optimizasyon yapın" ile eşdeğer değildir.

Diğer yorumların çoğuna katılıyorum - C programlarını daha hızlı yapmak için kullanılan şey bugün bunu yapamayabilir - ancak dikkate alınması gereken başka ciddi şeyler var: C veya C++ kullanmalı mıyım? Aşırı yüklenmiş basit operatörlere sahip sınıflar, çok kullanırsanız performansı öldürebilir. Önemi var? Uygulamanıza bağlıdır, ancak CONSIDER'ı bile düşünmüyorsanız, çok iyi bir programcı değilsiniz. Bazı millet yaklaşık 2 milisaniye boyunca düşünebilir ve reddetmek, ama çok fazla kelimenin tam anlamıyla bile düşünmüyorum düşünüyorum.

Gerçek şu ki, optimizasyon ile kodun okunması zorlaşabilir. Kodun yazılması daha uzun sürer. Kod biraz daha hızlı ve daha büyük bir büyüklük sırası arasında bir yerde olacaktır (bu nadirdir). Müşterileriniz muhtemelen farkı bilmeyecek.

Başka bir gerçek, insanların kodu yeniden kullanmaktan hoşlandığı ve nerede bittiği, onu yazdığınızdan oldukça farklı olabilir. Aniden insanlar umursabilir.

Örnek olarak, bir bilgisayara veya bir oyun konsoluna Angry Birds gibi bir şey yazdığınızı varsayalım. Fizik sisteminizdeki ve grafik sisteminizdeki optimizasyonu göz ardı ettiniz - çünkü 2.5 GHz çift çekirdekli bu gün temelde minimumdur ve oyununuz yeterince iyi çalışır. Sonra akıllı telefonlar gelir ve onu taşımak istiyorum. Oh lanet olsun, 600 MHz KOL çekirdek?

Bir web sitesini düşünün - Hot or Not gibi bir hafta sonu bir araya getirilen bir şey. Kullanışlı veritabanı ne olursa olsun, hızlı bir gelişme düşünerek her şeyi yazın, arkadaşlarınıza bir e-posta göndererek başlatın. Üç ay sonra sunucunuz aşırı yükten ölüyor ve ölçeklendirmek için yapabileceğiniz hiçbir şey yok. Bu her zaman olur. En büyük web sitelerinde yüzlerce kilowatt veya hatta megawatt olarak ölçülen güç faturaları vardır. Bunu düşünün, kod optimizasyonu ile kaydedilecek megawattlar var.

Babanızın dediği gibi, en azından düşünmelisiniz . Çoğu kişi "performans optimizasyonu" ve "yapmayın" hakkında hızlı bir quip ile masa üzerinde ne kadar performans olduğunu ve üzerinde parlak bile bilmiyorum. Bunlar iyi programcılar değil.

Bu, bu siteler hakkında popüler bir fikir değildir. Güle güle itibar puanları ....

27
phkahler

Önce durumunuzu ele alalım: PHP

  • PHP (hem doğası hem de ana uygulama alanı nedeniyle) bu "mikro-optimizasyon" hakkında endişelenmeniz gereken bir tür dil olduğunu sanmıyorum. PHP kodu çoğunlukla opcode önbellekleme ile optimize edilir.
  • PHP ile yazılan programlar CPU'ya bağlı değildir, çoğunlukla I/O bağlıdır, bu nedenle bu optimizasyonlar zaman ayırmaya değmez.
  • Optimize ETMEK GEREKEN her şey muhtemelen bir C uzantısına gizlenmeli ve daha sonra PHP çalışma zamanında dinamik olarak yüklenmelidir)
  • Gördüğünüz gibi, PHP - içindeki kodumuzu mikro-optimize ederek hiçbir teşvik almıyoruz, eğer PHP = daha okunabilir ve bakımı kolay - size daha fazla temettü ödeyecek.

Genel olarak,

"TOOOOO" kodumu Python veya Ruby - gibi dinamik bir dilde optimize etmek için çok fazla zaman harcamak istemiyorum, çünkü CPU yoğun sayı-crunching görevleri için tasarlanmış DEĞİLDİR . Gerçek bir dünya durumunu modellemenin (okunması ve bakımı kolay olan) - denilen ifade - hızdan daha önemlidir. Hız asıl endişe olsaydı, ilk etapta dinamik olmazlardı.

Derlenmiş programlar (C++, Java) için optimizasyon çok önemlidir. Ama orada da, önce yazdığınız programın doğasına/alanına/amacına bakmalısınız. Ayrıca, bu optimizasyondan elde edilen kazanımlara karşı mikro optimizasyon süresini dikkatlice tartmalısınız. Daha fazla optimizasyona ihtiyacınız varsa, aşağı doğru bir adım atmayı da düşünebilirsiniz - ve kodunuzun bu parçalarını montajcıda kodlayabilirsiniz.

Yani, orijinal sorunuzu cevaplamak için - "Kodlama sırasında mikro optimizasyon önemli mi?" -- Cevap, duruma bağlı --

  • Ne tür bir şey yapıyorsunuz: uygulama alanı, karmaşıklık?
  • Mikrosaniye hız iyileştirmeleri GERÇEKTEN programınız için önemli mi?
  • Ne tür bir optimizasyon en kazançlı olacak? Her zaman kod optimizasyonu değil, harici bir şey olabilir.
  • Mikro optimizasyon yaptığınız yatırımdan ne kadar "iyilik" (hız açısından) elde ediyorsunuz?
  • Donanımı, RAM & işlemciyi, paralel olarak kod yürüterek veya dağıtılmış bir sistemde) değiştirerek daha iyi hızlara ulaşılabilir mi?

Mikro optimizasyon (bu konu için kod optimizasyonu) zaman alıcı olmakla kalmaz, aynı zamanda kodunuzun doğal okunabilirliğini de "bozar" ve böylece bakımı ağır hale getirir. Her zaman son çare olarak düşünün - her zaman tek tek kod dosyalarını optimize etmekten daha iyi donanım ve daha iyi mimari benimseyerek tüm uygulamayı optimize etmeye çalışın.

25
treecoder

Mikro optimizasyonun

ödünleşim ile ilgili her şey - performans, zaman, maliyet, çaba, okunabilirlik/sürdürülebilirlik vb.

Ancak, okunabilirlik etkisi olmayan bazı optimizasyonların olduğunu biliyorum ve bunları eğlenmek için yapmayı seviyorum. Okul ödevlerimin bazılarında (hepsi hıza dayalı) gördüm, şunun gibi koşullu ifadeler yazarken mikro optimizasyonu düşünmenin her zaman güzel olduğunu gördüm:

if (counter < X && shouldDoThis()) // shouldDoThis() is an expensive function

her zaman daha iyidir

if (shouldDoThis() && counter < X ) 

Böyle kodunuzu "hızlandırmak" için oldukça az yolu vardır ve fark genellikle (her zaman olmasa da) genellikle ihmal edilebilir, ama ben böyle yazarsanız daha iyi hissediyorum.

Kimsenin bunu gerçekten bir optimizasyon olarak görüp görmediğini bilmiyorum, ama bir programcı kodlarını yazarken bu şeyleri bilmeli ve düşünmelidir.

18
zidarsk8

Kariyerimin başlarında, "mikro optimizasyon yapma" gibi battaniye ifadeleri çok fazla karışıklığa yol açtı. Her şey durumsaldır; bu yüzden insanların "bunu yap" yerine "en iyi uygulama" deme nedenleri.

"En iyi uygulama" her koşulda en iyi seçimdir. Örneğin, satır içi SQL yerine LINQ ve Entity Framework kullanılmalıdır. Şirketimde SQL Server 20 çalışıyoruz. SQL Server 2000, Entity Framework'ü desteklemez. En iyi uygulamalar şunları gerektirir:

  • Birkaç bin dolar anlamına gelen SQL Server'ın yeni bir sürümünü satın alma fikri üzerine patronumu satmak.
  • Geliştiricilere yeni teknoloji öğrenme fikri satmak.

Deneyimden biliyorum ki bu olmayacak. Böylece bırakabilirim, hiç durmadan stres atabilir veya en iyi uygulamayı takip edemezdim.

Genel sonucu etkileyen kararların arkasında siyasi, teknik ve parasal hususlar vardır. Karar verirken bu gerçeği hatırlayın ve savaşlarınızı akıllıca seçin.

" Her şey için bir mevsim var, cennetin altındaki her aktivite için bir zaman. "

11
P.Brian.Mackey

Bu her zaman bir ödünleşmedir.

Birincisi, bilgisayar endüstrisi sonunda parayla ilgilidir. Bir geliştirici olarak yapmanız gereken şey, müşteri için değer yaratmaktır, böylece para elde edersiniz (bu aşırı basitleştirme, ancak asıl nokta burada).

Geliştirici zamanının maliyeti. Makine gücü de maliyetlidir. Genellikle, bu ikinci maliyet birinciden çok daha düşüktür. Bu nedenle, bu, okunabilir bir koda ve sürdürülebilir bir koda sahip olmak için büyük önem taşır, böylece geliştirici zamanlarının çoğunu değer sunmak için harcayabilir.

Mikro optimizasyon bazı durumlarda önemli olabilir. Ancak genellikle daha az okunabilir kod veya daha az genişletilebilir kod içerir (bu, bağlantılı örneğinizin durumu değildir, ancak genel olarak geçerlidir). Bu, bir noktada geliştiricinin zamanına mal olacak. Bu sefer makine gücünden daha pahalı olduğundan, bu bir israftır.

İkincisi, büyük bir projedeki mikro optimizasyon, sürdürülmesini/gelişmesini zorlaştırabilir. Sorun şu ki, evrimleşirken, başka bazı optimizasyonların yapılması imkansız olabilir. Gelişen bir uygulama ile, genellikle bu optimizasyonları yapmadan sahip olacağınızdan daha yavaş bir çözüm elde edersiniz.

Üçüncüsü, algoritma karmaşıklığı genellikle veri kümesi büyürse yapabileceğiniz herhangi bir mikro optimizasyonun üstesinden geleceğinden optimizasyon genellikle geri döndürülemez. Ne yazık ki, mikro optimizasyon kodunuzun bakımını/geliştirilmesini zorlaştırdığından, optimizasyonun yapılması daha zor olabilir.

Bazen, bu optimizasyonda değer vardır (video oyunlarında veya bir uçağın otopilotunda olduğu gibi gecikme açısından kritik programları düşünün). Ancak bu kanıtlanmalıdır. Genellikle programınız çoğu zaman kodun sınırlı bir bölümünde kalır. Hangi mikro-optimizasyon yaparsanız yapın, darboğazı tespit etmeden ve bu parça üzerinde çalışmadan programlarınızı asla daha hızlı bir şekilde elde edemezsiniz.

Sorunuzu yaptığınız gibi sormak, sorunu gerçek bir programda kıyaslamadığınızı gösterdi. Bu durumda, hile yapabilir ve daha hızlı olup olmadığını fark edebilirsiniz. Yani herhangi bir problem yaşamadan bunu soruyordunuz. Sorun burada. Optimizasyon sorununu yanlış şekilde ele alıyordunuz.

Bakım ve evrim genellikle mikro optimizasyondan daha değerli olduğundan, herhangi bir işlem yapmadan önce doğru arayüze sahip olduğunuzdan emin olun. Ardından, programınızın bazı bölümleri birbirleri için yeterince soyutsa, her şeyi bozmadan birini optimize edebilirsiniz. Bu, arayüzünüzün güvenilebilecek kadar uzun süre çalışmasını gerektirir.

8
deadalnix

Performans Bir Özelliktir

Jeff Atwood'un makalesi, yüksek performanslı bir web sitesi oluşturmak ve bunu yapmanın önemi ...

Bununla birlikte, ihtiyacınız olana kadar mikro optimizasyona odaklanmayın. Yapabileceğiniz daha uygun maliyetli optimizasyon vardır. Kod değil mimariye odaklanın. Yavaş performans gösteren web sitelerinin çoğu, performansı olumsuz yönde etkilemekle kalmayıp, derinlemesine kökleşmiş ve düzeltilmesi zor olan yüksek düzeyde (gereksiz web hizmet katmanı, kötü veritabanı tasarımı, aşırı karmaşık mimariler) problemlere sahipti.

Bir web sitesi oluştururken, istemci tarafı kodunuzun ve veritabanı mantığınızın, sunucu tarafı kodunuzdan çok performans sorunlarına neden olma olasılığı daha yüksektir. Yine de herhangi bir şey gibi, performans problemleriniz varsa, kodunuzu daha iyi profille ve daha sonra bulabilirsiniz.

8
Mike Cellini

Neyi optimize etmek istersiniz?

  • Yazılım performansı?
  • Güvenilirlik?
  • Programcı verimliliği?
  • Müşteri memnuniyeti?
  • Güç verimliliği?
  • İdame?
  • Market zamanı?
  • Maliyet?

"Optimize et" her zaman kodun mümkün olduğunca hızlı çalışmasını sağlamak anlamına gelmez. Bir şey yapmanın en hızlı yolunu bulmanın önemli olduğu zamanlar vardır, ancak çoğu kodda bu kadar yaygın değildir. Kullanıcılar 50 ve 100 mikrosaniye arasındaki farkı fark edemezlerse, koddaki ikisi arasında ara sıra çalışacak etkin bir fark yoktur. İşte bir örnek:

Kullanıcının girdisinin uzunluğunu ve bu uzunluğun birbirini takip eden iki tuş vuruşu arasındaki süreden çok daha küçük olduğunu belirlemek için iki rutinden birini geçmesi gereken süreyi sürekli olarak güncellemeniz gerekiyorsa, hangi rutinin önemli olduğu önemli değildir. kullan. Öte yandan, bir milyar dizenin uzunluğunu belirlemeniz gerekiyorsa, muhtemelen farklı rutinler arasındaki performans farklılıklarına dikkat etmek isteyeceksiniz. İlk durumda, anlaşılması ve doğrulanması kolay bir kod yazmayı tercih edebilirsiniz; ikinci durumda, hız için okunabilirliği takas etmek isteyebilirsiniz.

Her durumda, kodunuzu optimize edecekseniz, yaptığınız değişikliklerden önce ve sonra kodunuzu profillemelisiniz. Bu günlerde programlar, darboğazların nerede olduğunu söylemek zor; profil oluşturma doğru kod optimizasyonuna yardımcı olur ve yaptığınız optimizasyonların gerçekten işe yaradığını gösterir.

Baban ne zaman emekli olduđunu veya ne tür bir program yaptýđýný söylemedin, ama tepkisi şaşırtıcı deđil. Tarihsel olarak, bellek, ikincil depolama ve bilgi işlem süresi pahalıydı ve bazen çok pahalıydı. Bugünlerde, tüm bunlar programcı zamanına göre çok ucuz hale geldi. Aynı zamanda, işlemciler ve derleyiciler, programcıların hiçbir zaman eşleşemeyeceği şekilde kodu optimize edebildiler. Programcıların birkaç makine talimatını yakmak için küçük numaralar kullandıkları ve çoğunlukla gitti.

7
Caleb

Kodu yazarken mikro optimizasyon yapmak önemli değildir. Optimizasyon, önemli olan bir kodu optimize ederek bir profil oluşturucunun yardımıyla yapılmalıdır.

ANCAK , bir programcı yazarken açıkça aptalca şeyler yapmaktan kaçınmalıdır. kodu.

Örneğin, bir döngü içinde tekrarlanan pahalı işlemleri yapmayın. Değeri döngü dışındaki bir değişkende saklayın ve bunu kullanın. Sıkça adlandırılan bir işlevde dize karşılaştırmaları veya regex gibi şeyleri tekrar tekrar yapmayın, bir düzey yukarı çıktığınızda, karşılaştırmayı yapın ve bir tamsayı veya işlev başvurusu veya türetilmiş bir sınıf haline getirin.

Bu şeyler, deneyimli bir programcının kod kalitesini hatırlaması ve neredeyse her zaman iyileştirmesi için kolaydır.

7
Zan Lynx

Geliştirici süresinin maliyeti bilgisayar süresinden daha fazladır. Genellikle optimize etmek istediğiniz şey budur. Ama:

  • Mikro optimizasyon ve algoritmik karmaşıklık arasında bir fark vardır. Doğru olanı kullandığınızdan emin olmak için yeterli zaman ayırın algoritma.
  • Doğru soruyu sorduğunuzdan emin olun, select (select count(*) from foo) >= 1, select exists(select 1 from foo) ile aynı şey değildir.
  • bazı dil deyimleri sadece daha hızlı oldukları için popülerdir, bunları kullanmakta sorun yoktur, çünkü dilin akıcı kullanıcılarının çoğu onlara aşina olacaktır. (örneğiniz iyi bir örnektir).

Neyin optimize edileceğine karar verirken her zaman unutmayın Amdahl yasası . Kesin matematik için bağlantıya bakınız; hatırlanması gereken özlü ifade:

Programınızın bir kısmı çalışma zamanının% 10'unu oluşturuyorsa ve bu parçayı iki kat daha hızlı çalışacak şekilde optimize ederseniz, bir bütün olarak program yalnızca% 5 oranında hızlanır.

Bu yüzden insanlar her zaman programınızın toplam çalışma süresinin yüzde birkaçından fazlasını işgal etmeyen kısımlarını optimize etmeye değmeyeceğini söylüyor. Ancak bu daha genel bir ilkenin özel bir örneğidir. Amdahl yasası, tüm programı iki kat daha hızlı çalıştırmanız gerekirse, her parça hızını ortalama% 50 hızlandırmanız gerektiğini söyler. Yirmi gigabayt veri işlemeniz gerekiyorsa, bunu diskten yirmi gigabayt okumak için geçen süreden daha hızlı hale getirmenin yalnızca iki yolu olduğunu söyler: daha hızlı bir disk almak veya verileri daha küçük yapmak.

Peki Amdahl yasası mikro optimizasyonlar hakkında ne diyor? Eğer tahta boyunca başvururlarsa belki de buna değer olduklarını söylüyor. Programınızdaki her işlevin çalışma süresinde yüzde bir tıraş olabilirseniz, tebrikler! Programı yüzde bir hızlandırdınız. Bu yapmaya değer miydi? Derleyici bir adam olarak bunu yapan bir optimizasyon bulmaktan memnuniyet duyarım, ancak elle yapıyorsanız, daha büyük bir şey arayın diyebilirim.

7
zwol

Hangi geliştirme aşamasında olduğunuza bağlıdır, ilk olarak bir şeyler yazmaya başlarken, mikro optimizasyonlar, mikro optimizasyonları kullanarak iyi algoritmalar kullanarak daha fazla performans kazanacağınız için dikkate alınmamalıdır. Ayrıca, zamana duyarlı uygulamalar genel optimizasyon uygulamalarından daha fazla fayda göreceğinden, ne geliştirdiğinizi düşünün.

Yazılımı test ediyorsanız ve genişletiyorsanız, mikro optimizasyonlar muhtemelen kodun okunmasını zorlaştırır ve hatta düzeltilmesi gereken başka bir şeyle birlikte düzeltilmesi gereken kendi benzersiz hata setini tanıtmaya eğilimlidir.

Kullanıcılardan yavaş kod hakkında şikayetler alıyorsanız, dikkate almaya değer olabilirler, ancak yalnızca her şey çözüldüyse, yani:

  • Kod iyi yazılmış mı?
  • Uygulama verilerine herhangi bir sorun olmadan erişebiliyor mu?
  • Daha iyi bir algoritma kullanılabilir mi?

Bu soruların hepsi yanıtlandıysa ve hala performans sorunları yaşıyorsanız, koddaki mikro optimizasyonları kullanmaya başlamanın zamanı gelmiş olabilir, ancak olasılıklar diğer değişikliklerin (yani daha iyi kod, daha iyi algoritma, vb.) bir mikro optimizasyondan daha fazla performans kazancı sağlar.

6
rjzii

Uygulama hızı, bir programın kalitesine katkıda bulunan birçok faktörden biridir. Çoğu zaman, hızın okunabilirlik/sürdürülebilirlik ile ters bir korelasyonu vardır. Hemen hemen tüm durumlarda, kod korunabilmesi için kodun okunabilir olması gerekir. Okunabilirliğin tehlikeye atılabileceği tek zaman, hızın önemli bir gereksinim olduğu zamandır. Kodu tam okunabilirlik/sürdürülebilirlikten daha hızlı hale getirme gereksinimi neredeyse hiç uygulanabilir değildir, ancak bunun olacağı bazı durumlar vardır. Hatırlanması gereken en önemli şey, mikro optimize edilmiş kodun genellikle haksız kod olmasıdır, bu nedenle bir yerde tanımlanmış bir gereksinim yoksa, sorunu çözmek için neredeyse her zaman yanlış yoldur. Örneğin, kullanıcı CRUD işlemlerinde .5 saniye ve 1 saniye yürütme süreleri arasındaki farkı neredeyse hiç fark etmeyecektir, bu nedenle bu .5 saniyeye ulaşmak için bir Assembly-interop-hackfest'e gitmenize gerek yoktur. Evet, çalışmak için bir helikopter uçabilirdim ve 10 kat daha hızlı olurdu, ancak fiyat ve helikopterin uçması çok daha zor olduğu için yapmıyorum. Kodu gereksiz yere mikro olarak optimize ettiğinizde, tam olarak yaptığınız şey budur: gereksiz bir hedefe ulaşmak için gereksiz karmaşıklık ve maliyet eklemek.

5
Morgan Herlocker

Bir kısıtlamaya ulaştığınızda mikro optimizasyon önemlidir. Önem verdiğiniz şey bellek, verim, gecikme veya güç tüketimi olabilir. Bunların sistem düzeyinde özellikler olduğunu unutmayın; her işlevi her şekilde optimize etmeniz gerekmez (ve yapamazsınız).

Gömülü sistemlerin mikro optimizasyona ihtiyacı vardır, çünkü kısıtlamalar daha kolay vurulur. Ancak, mikro-optimizasyon bile sizi şimdiye kadar götürür; Kötü bir tasarımdan çıkış yolunuzu mikro olarak optimize edemezsiniz. Bir sistemde iyi tasarımın anlamı, bir bütün olarak sistem hakkında akıl yürütmenizdir. Mikro optimizasyon gerektiren bileşenler, sistemin tasarımından ödün vermeyecek şekilde düzgün bir şekilde açığa çıkarılmalı ve optimize edilmelidir.

Bugün küçük "gömülü" sistemlerin Vaxen veya PDP-11s geçmişine oldukça yakın olabileceğini unutmayın, bu yüzden bu sorunlar daha yaygındı. Modern genel ticari hesaplama yapan modern bir genel amaçlı sistemde mikro optimizasyon nadirdir. Bu muhtemelen babanızın neden bu görevi üstlendiğinin bir parçasıdır.

Bununla birlikte, nanosaniye, milisaniye, saniye veya saat ile uğraşmak önemli değildir; sorunlar aynı. Sistem ve ne elde etmeye çalıştığınız bağlamında değerlendirilmelidirler.

Bu, mikro optimizasyonun gerekli olduğu bir durumda Stack Overflow üzerinde yanıtladığım son bir sorudan bir örnektir: Katıştırılmış için açık kaynaklı video kodlayıcılar sistem.

5
janm

Mikro optimizasyon ile ilgili en büyük sorun, bakımı daha zor bir kod yazmanıza neden olmasıdır.

Başka bir sorun bilgisayar yapılandırmasına bağlıdır, bazen mikro optimizasyon 'optimizasyon' olmadan en kötü performansa sahip olabilir.

Birçok mikro optimizasyon yapmak, gerçekten önemli olmayan bir şeyle mücadele etmek için çok zaman harcayacaktır.

Daha iyi bir yaklaşım, daha temiz bir kod yapmak, bakımı daha kolay yapmaktır ve performans sorunları yaşarsanız, kodunuzu gerçekten neyin yavaşlattığını anlamak için bir profil çalıştırırsınız. Ve gerçekten neyin gerçekten kötü olduğunu bilerek düzeltebilirsiniz.

Mikro-optimizasyon yapmamanın aptal kod yazmak için mazeret olduğunu söylemiyorum.

4
Daniel Moura

Daha önce söyledim ve burada söyleyeceğim: "Erken optimizasyon tüm kötülüklerin köküdür". Bu, herhangi bir programcının zihninin merkezindeki kurallardan biri olmalıdır.

Kod, bir noktaya kadar, şu anda olduğundan daha hızlı olabilir. Montajı belirli bir çip göz önünde bulundurarak elle paketlemediğiniz sürece, her zaman optimizasyon yoluyla kazanılacak bir şey vardır. Bununla birlikte, yaptığınız her şey için Montajı elle paketlemek istemiyorsanız, nicel bir hedef olmalı, bir kez buluştuğunuzda, "bu yeterli" deyin ve hala göze çarpan bir performans emici olsa bile optimizasyonu durdurun karşısındasın.

Güzel, zarif, son derece performanslı kod işe yaramazsa işe yaramaz (ve "iş" ile beklenen tüm girdiler verildiğinde beklenen çıktıyı üretmek anlamına gelir). Bu nedenle, çalışan kod üretmek HER ZAMAN birinci öncelik olmalıdır. Çalıştıktan sonra performansı değerlendirirsiniz ve yoksa, daha iyi hale getirmenin yollarını, yeterince iyi olduğu noktaya kadar ararsınız.

Performansı etkileyecek ön karar vermeniz gereken bazı şeyler vardır; Bu çözümü uygulamak için hangi dili/çalışma zamanını kullanacağınız gibi çok temel kararlar. Bunların birçoğu, bir yöntemi diğerine karşı çağırmaktan çok birçok büyüklük düzeyinde performansı etkileyecektir. Dürüst olmak gerekirse, PHP, bir betik dili olarak zaten bir performans hitidir, ancak C/C++ 'da aşağıdan yukarıya doğru çok az sayıda betik site oluşturulduğundan, muhtemelen seçebileceğiniz diğer teknolojilerle karşılaştırılabilir (Java Servlets, ASP.NET , vb).

Bundan sonra, G/Ç mesaj boyutu bir sonraki en büyük performans katilinizdir. Sabit disk, seri portlar, ağ boruları, vb. 'Den okuduklarınızı ve yazdıklarınızı optimize etmek, G/Ç işlemlerinin arkasındaki algoritmalar etkili olsa bile, programın çalışma süresini genellikle büyüklükte artırır. Bundan sonra, algoritmanın Big-O karmaşıklığını azaltın ve daha sonra kesinlikle yapmanız gerekiyorsa, daha az pahalı yöntem çağrıları seçerek ve düşük seviyelerde diğer ezoterik kararlar vererek "mikro-optimize edebilirsiniz".

4
KeithS

Milisaniye hakkında endişelenmeye başlarsanız, PHP ve bunun yerine C veya Assembly'yi kullanmayı düşünmelisiniz. kodlama dili kullanın Kodunuz bu komutla sık sık yineleniyor mu?

Çevresel faktörler burada söz konusu değil, bu sunucular zaten 7/24 çalışıyor ve bir şeyi gerçekten işlemeleri, sadece gerçekten çok uzun süre çalışan bir görev olup olmadığı önemli olacaktır.

Büyük olasılıkla ofisinizdeki ışık ve hepimiz soru ve cevap yazarken bilgisayarlarımızın kullandığı enerji, uygulamalarınıza makul şekilde uygulayabileceğiniz her türlü mikro optimizasyondan çok daha fazla enerji tüketmiştir.

4
thorsten müller

Babanızın emekli bir programcı olduğunu söylediniz. Ana bilgisayar dünyasında çalışan programcıların performans konusunda çok endişelenmeleri gerekiyordu. Ana bilgisayarlarının donanım başına kullanıcı tarafından 64 KB bellekle sınırlandırıldığı bir ABD Donanması etkinliğini okuduğumu hatırlıyorum. O programlama dünyasında, yapabileceğiniz her küçük parçayı dışarı atmanız gerekiyor.

Şimdi işler çok farklı ve çoğu programcının mikro optimizasyonlar hakkında çok fazla endişelenmesine gerek yok. Bununla birlikte, gömülü sistemler programcılar hala yapıyor ve veritabanı insanlarının hala optimize edilmiş kod kullanmaları gerekiyor.

4
HLGEM

Görev için en iyi, basit algoritmayı seçmelisiniz. Basit olmasının nedeni, kodu okunabilir tutmaktır. En iyi olmasının nedeni, kötü çalışma zamanı özellikleriyle başlamaktan kaçınmaktır. Büyük veri kümeleriniz olacağını bildiğinizde BubbleSort'u körü körüne seçmeyin. Bununla birlikte, ara sıra 10 element için iyidir.

Daha sonra, profil oluşturma numaraları en iyi, basit algoritma seçiminizin yeterince iyi olmadığını gösteriyorsa, optimizasyona başlayabilirsiniz (genellikle okunabilirliğin maliyeti olarak).

4
user1249

Kodlama yaparken mikro optimizasyon önemli mi?

Hayır, JVM ve . NET gibi sanal bir makine için kod yazıldığı ve böylece yürütmeyi optimize etmeye çalıştığı platformlar olduğu göz önüne alındığında geliştiricinin masaüstünde en uygun olanın bir sunucuda aynı olması gerektiği gibi çalışmayabilir. Bu üst düzey yazılım parçalarının bir kısmının donanımdan ne kadar uzak olduğuna bakın. Dikkate değer bir şey donanım çeşitliliği verilir, yeni bir model muhtemelen bir yıldan daha kısa sürede çıkacaksa, CPU veya GPU gibi belirli yongalar için kodu optimize etmek ne kadar gerçekçi?

Burada dikkate alınması gereken bir diğer soru, hangi metriğe göre ölçülen performanstır: Yürütme hızı, yürütmede kullanılan bellek, yeni özelliklerin geliştirme hızı, derlenmiş veya derlenmemiş biçimlerde bir sunucudaki kod tabanının boyutu, ölçeklenebilirlik, sürdürülebilirlik, vb. .? Yeterince geniş çapta alınırsa, soru önemsiz hale gelir, ancak bir şekilde ölçülebildiği sürece hemen hemen her şey olabilen gerçekten ne kadar geniş bir şekilde performans almak istediğinizden emin değilim.


Bazı mikro optimizasyonlar işe yarayabilir ve bazıları çalışmayabilir, bu da yeni özellikler veya sabitleme hataları gibi daha yüksek öncelikli olabilecek diğer çalışmalara kıyasla bu tür bir çalışmanın ne kadar değerli olduğunu merak edebilir. Diğer soru, donanım veya yazılım yükseltmesinin bu optimizasyonlardan bazılarını bozup bozmayacağıdır.

3
JB King

Kod, ne yaptığına dair net olmak için yazılmalıdır. Sonra, if ve sadece if çok yavaş, geri dönün ve hızlandırın. Kod daha sonra anlaşılabilirse daha sonra daha hızlı olacak şekilde değiştirilebilir, ancak iyi şanslar hızlıysa net olacak şekilde değiştirilir.

3
DeadMG

Aşağıdaki durumlarda önemlidir:

1) Birinin hayatı kodunuza bağlıdır. Birinin kalp atış hızı monitöründe 25 ms süren bir işlev muhtemelen kötü bir fikirdir.

Şahsen iki yönlü bir yaklaşım benimsiyorum - okunabilirliği etkilemeyecek mikro optimizasyonlar var - tabii ki bunları kullanmak istiyorsunuz. Ancak okunabilirliği etkiliyorsa, uzak durun - fazla fayda elde edemezsiniz ve aslında uzun vadede hata ayıklamanız daha uzun sürebilir.

3
ansiart

IMHO kod okunabilirliği mikro optimizasyondan daha önemlidir, çünkü çoğu durumda mikro optimizasyon buna değmez.

Makale anlamsız mikro optimizasyonlar hakkında :

Çoğumuz olarak, echo ile yazdırmayı, ++ $ i ile $ i ++ veya tek tırnakla çift tırnak değiştirmek gibi anlamsız mikro optimizasyonlarla ilgili blog yayınlarını okumaktan yoruldum. Neden? Çünkü zamanın% 99.999999'u alakasızdır. Neden? Çünkü% 99,99, bir PHP APC gibi bir hızlandırıcı yüklemeniz veya bu eksik dizinleri veritabanı sütunlarınıza eklemeniz veya ana sayfada sahip olduğunuz 1000 veritabanı isteğinden kaçınmaya çalışmanız gerekir .

print aslında bir şey döndürdüğü için bir opcode daha kullanır. Yankının baskıdan daha hızlı olduğu sonucuna varabiliriz. Ancak bir opcode'un hiçbir maliyeti yoktur, gerçekten hiçbir maliyeti yoktur.

Yeni bir WordPress kurulumda denedim. Komut dosyası, dizüstü bilgisayarımdaki bir "Bus Hatası" ile bitmeden önce duruyor, ancak opcodes sayısı zaten 2.3 milyondan fazlaydı.

Bu nedenle çoğu durumda mikro optimizasyon milyonlar arasında 1 işlem tasarrufu sağlar, ancak okunabilirliği daha da kötüleştirir.

1
webvitaly

İyi programlama ve mikro optimizasyon arasında büyük bir fark olduğunu düşünüyorum.

Aynı görevi yapmanın iki yolu varsa, biri diğerinden daha hızlı ve ikisi de aynı okunabilirliğe sahipse, daha hızlı kullanmalısınız. Her zaman. Ve bu iyi bir programlama. Bir sorunu çözmek için daha iyi bir algoritma kullanmamak için hiçbir neden yoktur. Ve bunu belgelemek bile kolaydır: algoritma adını verin, herkes google'ı kullanabilir ve nasıl çalıştığı hakkında daha fazla bilgi bulabilir.

Ve iyi algoritmalar zaten optimize edilmiştir. Hızlı olacaklar. Küçük olacaklar. Gerekli olan minimum belleği kullanırlar.

Bunları kullansanız bile, programınız hala bu performansa sahip olmasalar bile, mikro-optimize etmeyi düşünebilirsiniz. Ve mikro optimizasyon yapabilmek için dili gerçekten bilmeniz gerekir.

Ve her zaman donanıma daha fazla para harcamak için yer vardır. Donanım ucuz, programcılar pahalı . Sadece donanım satın alabileceğinizi optimize ederek çok fazla zaman/para harcamayın.

1
woliveirajr

"Buna değer", yazmanın ve okumanın ve sürdürmenin ne kadar daha basit olduğu gibi içeriğe ihtiyaç duyuyor ve bunun ne kadar hızlı olduğunu kullanıcı önemli ölçüde daha duyarlı, etkileşimli, beklemeleri için daha az zaman gerektirir.

Bir kutu soda satın almak için birkaç peni kaydetmek, özellikle bu günlerde nadiren soda içtiğim göz önüne alındığında, bu pennies'i kurtarmak için bir mesafe seyahat etmem gerekirse bana çok iyi gelmeyecek. Bir milyon kutu soda satın alırken kutu başına birkaç peni kurtarmak büyük bir anlaşma olabilir.

Bu arada iki kişi hemen yanımda olduğunda birkaç peni kurtarmak ve biri birkaç peni için daha ucuza aynı şeyi sunuyor ve diğeri değil ve daha pahalı olanı seçiyorum çünkü şapkalarını daha iyi beğeniyorum aptalca bir dava gibi görünüyor kötümserlik.

Sık sık "mikro-optimizasyon" olarak adlandırılan insanları bulduğum şey, meraklı olmadıkları takdirde bu tür optimizasyonları dikkate almak için üçünün de olması gerektiğinde, ölçümlerden ve bağlamdan ve kullanıcı-son tartışmasından yoksun görünüyor. Benim için bu günlerde uygun bir mikro-optimizasyon, bellek düzenleri ve erişim kalıpları ile ilgilidir ve odakta "mikro" gibi görünseler de, mikro olarak etkili değildirler.

Çok uzun zaman önce, hacimsel ısı dağılımı difüzyonu için algoritmik karmaşıklıkta bir değişiklik olmadan, aynı çıktılarla (otomatik testlerle güvence altına alınmış) 24 saniyeden 25 milisaniyeye (yaklaşık 960 kat daha hızlı) bir işlemi azaltmayı başardım. "mikro-optimizasyonlar" (en büyüğü bellek düzeninde yaklaşık 2 saniyeye ulaşan bir değişiklikten geldi, o zaman geri kalanı SIMD ve VTune'deki önbellek hatalarının daha fazla analizi ve bellek düzeninin yeniden düzenlenmesi gibi şeylerdi).

Wolfire buradaki tekniği açıklıyor ve gerekli zamanla mücadele ediyor: http://blog.wolfire.com/2009/11/volumetric-heat-diffusion-skinning/

Uygulamam bunu bir dakikadan daha kısa bir sürede indirmeye çalışırken milisaniye içinde yapabildi: enter image description here

24 saniyeden 25 ms'ye "mikro optimize" ettikten sonra, bu iş akışında bir oyun değiştiriciydi. Artık sanatçılar, teçhizatlarında her küçük değişiklik yaptıklarında 24 saniye beklemeden teçhizatlarını gerçek zamanlı olarak 30 FPS üzerinde değiştirebilirler. Ve bu aslında yazılımımın tüm tasarımını değiştirdi, çünkü artık ilerleme çubuğuna ve bu tür şeylere ihtiyacım yok, hepsi etkileşimli hale geldi. Bu, tüm iyileştirmelerin algoritmik karmaşıklıkta herhangi bir iyileştirme yapılmadan geldiği anlamında bir "mikro optimizasyon" olabilir, ancak daha önce acı verici, etkileşimli olmayan bir süreç haline getiren aslında oldukça "mega optimizasyon" idi. Kullanıcıların çalışma şeklini tamamen değiştiren gerçek zamanlı, etkileşimli bir.

Ölçüm, Kullanıcı Sonu Gereksinimleri, Bağlam

Robert'ın buradaki yorumunu gerçekten çok sevdim ve belki istediğim noktayı yapamadım:

Hadi bakalım. Kimse bu tür bir değişikliğin "buna değmediğini" iddia etmeyecek. Somut bir fayda gösterebildiniz; mikro optimizasyon denilen pek çok şey yapamaz.

Bu, çoğu zaman gerçek zamanlı gereksinimleri olan çok performans açısından kritik bir alanda çalışmasına rağmen, yolumdan çıkmayı gerektiren herhangi bir mikro optimizasyonu dikkate aldığım tek zamandır.

Ve sadece ölçümleri değil, kullanıcı sonunu da vurgulayacağım. Şu anki alanım (ve eskiden gamedev) önce kullanıcı/hayran olarak geliştirici ikinci olarak geldiğim için tuhaf biriyim. Bu yüzden, teknik bulmacaları çözmek gibi programcıları heyecanlandıran olağan şeylerden asla bu kadar heyecanlı değildim; Onlara bir yük buldum, ancak diğer kullanıcılarla paylaştığım kullanıcı sonu rüyasında onlara katılırdım. Ancak bu, herhangi bir şeyi optimize edersem emin olmama yardımcı oldu, gerçek faydaları olan kullanıcılar üzerinde gerçek bir etkisi olurdu. Bu, amaçsızca mikro optimizasyona karşı korumam.

Bu bence profiler kadar önemli, çünkü bir küpün mikro optimizasyonunu milyarlarca yüze ayırmak gibi şeyler yapan meslektaşlarım vardı, sadece karakterler ve araçlar gibi gerçek dünya üretim modellerini boğmak için. Sonuçları bazı "teknoloji demosu" anlamında etkileyiciydi, ancak gerçek kullanıcılar için neredeyse işe yaramazdı, çünkü gerçek dünyadaki kullanım durumlarıyla uyumlu olmayan davaları profillemek ve ölçmek ve kıyaslamak. Dolayısıyla, yazılımı düşünmeyi ve bir tane gibi kullanmayı öğrenerek veya onlarla işbirliği yaparak (ideal olarak her ikisi de, en azından onlarla işbirliği yaparak) önce kullanıcılar için neyin önemli olduğunu anlamak çok önemlidir. Mikro almak ve tıraş döngüleri ve önbellek özlediklerini başlatmak istiyorsak benim için en önemli şey, bunu yapmak için yoldan çıktığımız yeri önceliklendirmede gerçekten iyi olmaya başlamaktır (bu, doğal olarak bilmemiz gereken tüm yerleri bilmeye karşılık gelir) hem profil oluşturucu hem de kullanıcı sonu anlayışının çok önemli olduğu bunu yapmayın).

1
Dragon Energy

Diğer cevaplar doğru parayla. Ancak, bir kişinin erken optimizasyon/mikro optimizasyonun ne olduğunu ayırt etmesi gereken başka bir nokta ekleyeceğim ve dil/çerçeve yapılarının davranışının bir anlayışını yansıtan performans kodu yazma (üzgünüm, bulamadım) son bir kelime). Sonuncusu bir iyi bir kodlama uygulamasıdır ve genellikle yapılması gerekir!

Açıklayacağım. Kötü optimizasyon (erken/mikro optimizasyon okuma) kod bölümlerini gerçekten darboğaz olup olmadığını bilmek için profil oluşturmadan optimize ettiğinizde değildir. O zaman varsayımlarınıza, işittiğinize ve belgelenmemiş davranışlarınıza göre optimizasyon yaptığınız zamandır. Belgelenir ve daha küçük bir şey olsa daha verimli/mantıksal şekilde yaparsa, iyi optimizasyon diyorum. Diğerlerinin de belirttiği gibi, her ikisinin de eksileri vardır ve iyi iş kazanmakla ilgili olarak neredeyse hiç artıları yoktur, ancak eğer değilse, ikincisini değil, ikincisini yapıyorum tamamen yenmek = okunabilirlik. Evet okunabilirlik/bakım kolaylığı son derece önemlidir ve çizgiyi nereye çizdiğinizle ilgilidir.

Burada hem iyi hem de kötü optimizasyonların yararsızlığı olarak başkaları tarafından yapılan noktaları tekrarlayacağım:

  1. Belirli bir soruna olan bağımlılığınız değişebilir ve optimizasyon için harcanan her zaman mantıksal bölümü tamamlamadan önce uygulamanızın zaman kaybıdır. Yani nispeten erken bir aşamada optimizasyon yapmak. Bugün bir List<T> Var ve uygulamanız gönderildiğinde LinkedList<T> Olarak değiştirmek zorunda kaldınız ve şimdi tüm kıyaslama zaman ve çaba kaybıydı.

  2. Çoğunlukla uygulamanızın gerçek darboğazı (ölçülebilir fark olarak okunur) kodunuzun% 5'i (çoğunlukla sql olanlar) olabilir ve diğer% 95'i optimize etmek müşterilerinize herhangi bir fayda sağlamaz.

  3. Genellikle "teknik olarak" daha iyi performans gösteren kod daha fazla ayrıntı anlamına gelir, bu da daha fazla hataya açık kod anlamına gelir, bu da daha zor bakım ve daha fazla zaman harcanması anlamına gelir ve bu da daha az para kazanmanız anlamına gelir.

  4. % 1 performans artışı ile tüm dünya için kaydettiğiniz karbon ayak izi, ekibinizin bu kodu hata ayıklama ve koruma konusunda yayması gereken sera gazları tarafından kolayca cüce edilir.

Özellikle kötü optimizasyon negatifleri:

  1. Size genellikle beklediğiniz performansı vermez. optimizasyonlarının yanlış gittiği SO için bu soruya bakın. Aslında can olumsuz etkileri var. Belgelenmemiş davranıştaki sorun bu.

  2. Çoğunlukla modern derleyiciler bunu sizin için yapacak.

Bazı kötü ve iyi optimizasyon örnekleri vereceğim:

Kötü -

  1. Int32 yerine daha küçük tamsayı türlerinin kullanılması.

  2. ++i Yerine i++ Kullanıldı

  3. for yerine foreach (gördüğüm en kötüsü, mantığı tamamen yener)

  4. kapalı değişkenlerden kaçınmak

    string p;
    foreach (var item in collection)
        p = ...;
    
  5. dize birleştirme sırasında dize yerine char kullanarak, örneğin:

    string me = 'i' + "me myself"; // something along that line - causes boxing
    

İyi (.NET dünyasından. Açıklayıcı olmalı) -

  1. Çift arama

    if (Dictionary<K, V>.TryGetValue(K, out V))
        do something with V
    

    onun yerine

    if (Dictionary<K, V>.ContainsKey(K))
        do something with Dictionary<K, V>[K]
    
  2. Hepsini yükle

    DirectoryInfo.EnumerateFiles();
    

    onun yerine

    DirectoryInfo.GetFiles();
    
  3. İki aşamalı döküm:

    s = o as string;
    if (s != null)
        proceed
    

    onun yerine

    if (o is string)
        s = (string)o;
    
  4. Sipariş önemli değilse

    if (counter < X || expensiveFunction())
    

    onun yerine

    if (expensiveFunction() || counter < X)
    
  5. Boks

    void M<T>(T o) //avoids boxing
    {
    
    }
    

    onun yerine

    void M(object o)
    {
    
    }
    

Bunların gözle görülür bir performans avantajı sağlayıp sağlamadığını sorarsanız, hayır derim. Ama birinin bunları kullanmasını öneriyorum çünkü bu yapıların davranışlarının anlaşılmasından kaynaklanıyor. Sadece 1 yapabiliyorken neden iki arama yapıyorsunuz? Felsefi açıdan iyi kodlama uygulaması. Ve 1 ve 3 katı terimlerle biraz daha az okunabilir, ancak okunabilirliği gölgede bırakıyorlar mı? Hayır, fazla değil, bu yüzden kullanıyorum. Şimdi önemli olan - iyi bir performansın okunabilirlik oranını korumak. Ve bu olduğunda, çizgiyi nereye çizdiğinizle ilgili.

1
nawfal

Yaklaşık 31 yıl önce, bellek ve CPU'nun az olduğu programlamaya başladım. Belki de babanla aynı fikirdeyim.

İyi bir kodlayıcının her kod satırında optimizasyon konusunda endişelenmesi gerektiğine inanıyorum. Ama ben bu cümleye eklerdim: değerinde olduğu kadar ve her zaman yapmaya çalışıyorum hesaplamaların kritik olmadığı yerlerde optimizasyonda okunabilirliği destekleyin.

Örneğin, başka bir iş parçacığında, bir adam aşağıdaki kodu sordu, hangi çözümü seçeceğini: CPU veya Bellek.

public class Main {

    public static int totalRevenue;
    public static int totalProfit;

    public static int option1(int numSold, int price, int cost) {
        // Option 1 (memory)
        totalRevenue += numSold * price;
        totalProfit += numSold * price - numSold * cost;
        return numSold * price;
    }

    public static int option2(int numSold, int price, int cost) {
        // Option 2 (time)
        int saleRevenue = numSold * price;
        totalRevenue += saleRevenue;
        totalProfit += saleRevenue - numSold * cost;
        return saleRevenue;
    }
}

Bu kod aşağıdaki bayt kodunu oluşturur:

public class Main {
  public static int totalRevenue;

  public static int totalProfit;

  public Main();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method Java/lang/Object."<init>":()V
       4: return

  public static int option1(int, int, int);
    Code:
       0: getstatic     #2                  // Field totalRevenue:I
       3: iload_0
       4: iload_1
       5: imul
       6: iadd
       7: putstatic     #2                  // Field totalRevenue:I
      10: getstatic     #3                  // Field totalProfit:I
      13: iload_0
      14: iload_1
      15: imul
      16: iload_0
      17: iload_2
      18: imul
      19: isub
      20: iadd
      21: putstatic     #3                  // Field totalProfit:I
      24: iload_0
      25: iload_1
      26: imul
      27: ireturn

  public static int option2(int, int, int);
    Code:
       0: iload_0
       1: iload_1
       2: imul
       3: istore_3
       4: getstatic     #2                  // Field totalRevenue:I
       7: iload_3
       8: iadd
       9: putstatic     #2                  // Field totalRevenue:I
      12: getstatic     #3                  // Field totalProfit:I
      15: iload_3
      16: iload_0
      17: iload_2
      18: imul
      19: isub
      20: iadd
      21: putstatic     #3                  // Field totalProfit:I
      24: iload_3
      25: ireturn
}

Anlaşılabilirlik uğruna, 'iload_' veriyi yığından yükle ve 'istore_' verileri yığına kaydedin.

Daha fazla CPU döngüsü harcayan bir çözümde gerçekten bir bellek ayırma kaydettiğinizi fark etmek kolaydır. Bu tür bir soru deneyimli programcılar için bile ortaya çıkabilir.

Ancak bu örnekte bir yakalama vardır: yığın belleği, bayt düzeyinde değil, bloklar halinde önceden ayrılmıştır. Bir iş parçacığı her çalıştığında, yığın işlemlerinde kullanmak için belirli bir miktarda bellek ayırır. Bu nedenle, bu 4 bayt yığınınızı taşacak kadar şanslı değilseniz (ve daha büyük bir yığın boyutu kurmanızı gerektiriyorsa), her iki örneği de çalıştırmak için aynı bellek miktarını harcayacaksınız. Ancak ikincisinde, matematik hesaplamaları yaparak daha fazla döngü harcıyorsunuz ve kodunuz daha az okunabilir.

Buraya, küçük kod bölümlerindeki optimizasyonları tartışmanın kötü olmadığını gösteren bir örnek verdim. Bir adam bu konuyu bu konuyu işaret ederek kapattı. Ancak bu konu o soruya cevap vermiyor. Sadece "optimizasyon hakkında endişelenme" hakkında tartışır. Ve bu aptal mantra nedeniyle, insanlar bunun derin anlayışa doğru gitmediğini düşünüyorlar.

Bu soruya makul bir cevap var ve belki de iç kısımlar hakkında daha iyi bir cevap verebilir. İyi bir programcı öğrendikten sonra bu modeli içgüdüsel olarak tekrarlayabilecek ve daha iyi bir programcı olacaktır. Programcılar kodları hakkında eleştirel düşünmeye sahip olmalı ve mümkün olduğunca makinenin kodu nasıl işleyeceğini anlamaya çalışmalıdır.

Burada küçük şeyleri optimize etmemiz gerektiğini savunmuyorum. Mikro optimizasyonlara göre okunabilirliği tercih ettiğimi unutmayın.

Sadece "optimizasyon konusunda endişelenme" mantrasını tekrarlamanın işleri daha iyi hale getirmediğine inanıyorum. Sadece programcıları tembel yapar. Programcılar, olayların perde arkasında nasıl çalıştığını bilmek için teşvik edilmelidir. Bu şekilde insanlar daha iyi kod yazmaya çalışabilir ve akıllıca optimize etmemeyi akıllıca seçebilir.

0

Bu şekilde koyacağım - mikro optimizasyon, hiç bir darboğaz olmayan bir şeyi optimize etme sürecidir. Örneğin, programınız A ve B gibi iki işlevi çağırırsa ve A'nın tamamlanması 100 milisaniye alır ve B 2 mikrosaniye alırsa ve B işlevini optimize etmeye devam ederseniz, bu sadece önemli değil, bu kesinlikle yanlıştır. Ancak optimizasyon fonksiyonuna mikro optimizasyon değil optimizasyon denir. Optimizasyonun önemi bağlıdır. Yapacak başka bir şeyiniz olmadığını ve programınızın hatasız olduğunu varsayalım, o zaman evet, önemlidir. Ama genellikle öncelikleriniz var. Diyelim ki C fonksiyonunu eklemeniz/yazmanız gerekiyor. Eğer C fonksiyonunu yazmanın, bu fonksiyon olmadan programınızı daha hızlı hale getirmekten daha fazla para kazanacağını düşünüyorsanız optimizasyona gidin. Aksi takdirde işlevselliği sürdürün. Ayrıca, performansa odaklanmış deneyimli programcılar optimizasyon için fazla zaman harcamazlar, sadece hızlı programlar yazarlar. En azından hangi araçları kullanacağını ve yıllarca anlamsız (mikro okuma) optimizasyonlar yaparak neyi harcamayacaklarını biliyorlar.

0
user11408

Mikro optimizasyonlar ve mikro optimizasyonlar var. VB (hem VB6 hem de VB.NET, ancak IsNullOrEmpty çerçeveden teklif yoksayılır) her zaman _str <> ""_ yerine Len(str) <> 0 kullanıyorum Ancak, normalde ikincisini kullandıkları diğer kodları "düzeltmez".

Evet, ikincisi daha okunabilir, ancak bu durumda, birincisi okunamaz.

Kod tasarlanırken performans dikkate alma olmalı, ancak okunabilirlik ve sürdürülebilirlik gözetiminde olmamalıdır.

0
Mark Hurd