Kodlamada mikro optimizasyon önemli midir?


178

Neden Geçenlerde öğrenmek için Yığın taşması bir soru sordu isset () () strlen daha hızlıydı içinde PHP . Bu, okunabilir kodun önemi ve koddaki mikro saniye performans iyileştirmelerinin dikkate değer olup olmadığına dair sorular ortaya koydu.

Babam emekli bir programcı ve ben ona cevapları gösterdim. Bir kodlayıcının mikro düzeyde bile kodlarındaki performansı göz önünde bulundurmaması durumunda, programcı olmadıklarından kesinlikle emindi.

O kadar emin değilim - belki de bilgisayar gücündeki artış, artık bu tür mikro-performans geliştirmelerini dikkate almak zorunda olmadığımız anlamına geliyor? Belki de bu şekilde düşünmek gerçek dil kodunu yazan kişilere kalmıştır. (Yukarıdaki örnekte PHP).

Çevresel faktörler önemli olabilir - İnternet dünya enerjisinin% 10'unu tüketiyor. Milyonlarca web sitesinde trilyonlarca kez çoğaltıldığında, birkaç saniye mikro kodun ne kadar israf ettiğini merak ediyorum.

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

Kodlamada mikro optimizasyon önemli midir?

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

Bazen mikro-optimizasyonlar için gerçekten endişelenmemiz gerekir, ancak yalnızca çok nadir durumlarda. Güvenilirlik ve okunabilirlik çoğu durumda çok daha önemlidir. Ancak, zaman zaman mikro optimizasyon düşünülmesi zarar vermez. Temel bir anlayış, aşağıdaki gibi kodlama yaparken bariz kötü seçimler yapmamamı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 kodu değiştirmek mikro optimizasyon olur. Ancak, temel bir anlayışla, bunu yapmak zorunda değilsiniz, çünkü ilk önce doğru yazdınız.


123
Babanın tavsiyesi eskimiş . Performansı ne kadar geliştirdiğini sormam. Darboğazın nerede olduğunu sorardım. Genel bir fark yaratmazsa, bir kod bölümünün performansını artırmanızın bir önemi yoktur, en yavaş bağlantınız hızı belirleyecektir. PHP'de bu ağa yazıyor (aksi halde IE ölçüsünü kanıtlayamazsanız); daha okunaklı kod yazmaya dönüştüren daha önemlidir.
Martin York

61
Anahtar kelime göz önünde bulundurulursa yanlış değildir. Bununla ilgili bir ipucuna sahip olmalısın.
JeffO

37
Üzgünüm çünkü ünlü Erken Optimizasyon teklifinden henüz bahsedilmedi: "Programcılar, programlarının kritik olmayan bölümlerinin hızını düşünerek veya endişelendirip çok fazla zaman harcıyorlar ve verimlilik konusundaki bu girişimlerin gerçekten de olumsuz bir etkisi var hata ayıklama ve bakım dikkate alındığında etkisi vardır. Küçük verimleri unutmalıyız, zamanın yaklaşık% 97'sini şunu söylemeliyiz: erken optimizasyon tüm kötülüklerin kaynağıdır . Ancak bu kritik% 3'teki fırsatlarımızı aşmamalıyız. ”
Tamara Wijsman

13
"Dünya enerjisinin% 10'u" için bir kaynak sağlayabilir misiniz?
Michael Easter,

17
coder does not consider performance in their code even at the micro level, they are not good programmersmikro optimizasyondan çok farklı. Sadece iyi kodlama.
woliveirajr

Yanıtlar:


90

Hem babanla hemfikirim ve hemfikirim. Performans erken düşünülmeli, fakat mikro optimizasyon sadece erken düşünülmeli, gerçekte zamanın yüzde yüksek bir kısmının küçük CPU'ya bağlı kod bölümlerinde harcanacağını biliyorsanız .

Mikro optimizasyondaki sorun, genellikle programların gerçekte gereğinden fazla zaman harcadıkları konusunda hiçbir fikriniz olmadan yapılmasıdır.

Bu bilgi, performans ayarlaması deneyiminden, bu örnekte olduğu gibi , belirgin bir verimsiz görünmeyecek kadar basit bir programın, başlangıçtan 43 kat daha hızlı olana kadar bir dizi teşhis ve hızlandırma adımından geçirildiği durumlarda gelir.

Gösterdiği şey, sorunların nerede olacağını gerçekten tahmin edemeyeceğiniz ya da sezemeyeceğinizdir. Benim durumumda rastgele duraklatma olan tanı koyarsanız , zamanın önemli bir bölümünü oluşturan kod satırları tercihen ortaya çıkar. Bunlara bakarsanız, ikame kodunu bulabilir ve böylece kabaca bu kesirle toplam zamanı azaltabilirsiniz.

Düzeltmediğiniz diğer şeyler, daha önce olduğu kadar zaman alır, ancak genel süre azaldığından, bu şeyler şimdi daha büyük bir kesir alır, böylece hepsini tekrar yaparsanız, kesir de ortadan kaldırılabilir. Bunu birden fazla yineleme üzerinde yapmaya devam ederseniz , mutlaka herhangi bir mikro-optimizasyon yapmadan muazzam hızlanma elde edersiniz .

Bu tür deneyimlerden sonra, yeni programlama problemlerine yaklaştığınızda, başlangıçta bu gibi verimsizliklere yol açan tasarım yaklaşımlarını tanıdınız. Tecrübelerime göre, aşırı veri yapısı tasarımı, normalize olmayan veri yapısı, bildirimlere büyük ölçüde güvenme, böyle bir şeyden geliyor.


120

Mikro-optimizasyon sadece sayılar söylüyorsa önemlidir.

Geliştirmekte olduğunuz gereksinimler, performans müşteriyle veya kullanıcı için bir sorunsa, performans verisinde bazı spesifikasyonlar olmalıdır. Yazılım geliştirirken, sisteminizin performansını bu gereksinimlere karşı test etmelisiniz. Performans gereksinimlerini karşılamıyorsanız, kod tabanınızı profillemeniz ve performans gereksinimlerine ulaşmak için gerektiği gibi optimize etmeniz gerekir. Gereken minimum performansın içine girdiğinizde, özellikle de kodun okunabilirliğini ve bakımını daha fazla tehlikeye atacaksanız, (benim deneyimime göre, yüksek oranda optimize edilmiş kod daha az okunabilir ve bakımı yapılabilir, ancak her zaman değil). Sistemin diğer niteliklerini bozmadan ek performans kazancı elde edebiliyorsanız,

Ancak, performansın en önemli olduğu durumlar vardır. Ben esas olarak gerçek zamanlı sistemler ve gömülü sistemler düşünüyorum. Gerçek zamanlı sistemlerde, işlemlerin sırasının değiştirilmesi, uygun işlem için gerekli olan zor tarihlerin karşılanmasında, hatta hesaplamaların sonuçlarını etkilemede büyük bir etkiye sahip olabilir. Gömülü sistemlerde, genellikle sınırlı bellek, CPU gücü ve (pil gücünde olduğu gibi) gücünüz vardır, bu nedenle ikili sisteminizin boyutunu azaltmanız ve sistem ömrünü en üst düzeye çıkarmak için hesaplama sayısını azaltmanız gerekir.


Öte yandan, daha yavaş ve daha hızlı bir işlev kullanmak arasında bir sorun varsa, yavaş işlevini kullanmak için hiçbir neden yoktur - örneğin, isset durumunda olduğu gibi.
Mavrik

7
@Mavrik Bu doğru. İki işleviniz varsa, X ve Y ve Y, X'ten daha hızlıysa (en azından özel koşullarınız için), kod hala okunabilir ve bakımları yapılabilirse, Y kullanmamanız için hiçbir neden yoktur. Ancak Y'yi bilmiyorsanız ve X yerine Y kullanmak için yeniden kodlama koduna ihtiyacınız varsa ve performans (bu kod bölümünün performansı) bir sorun değilse, o zaman bu değişikliği yapmanın bir nedeni yoktur. Her şey değişimlerle ilgilidir - performans, zaman, maliyet, çaba, okunabilirlik / bakım kolaylığı vb.
Thomas Owens

2
Tüm kalbimle aynı fikirdeyim, sadece mikro optimizasyon söz konusu olduğunda bu noktaya değinmek istedim - eğer okunabilirlik / zaman açısından herhangi bir maliyete mal olmazsa, bunu yap. Aksi takdirde yapmayın.
Mavrik

+1 derece optimize edilmiş kod daha az okunabilir ve bakım yapılabilir ... ancak her zaman değil.
Boz

Performansın önemli olduğu diğer durumlar: (1) oyun; (2) büyük miktarda veri; (3) yüksek trafikli web sitesi; (4) oldukça karmaşık bir UI'nin tepkisi; (5) virüs kontrolü gibi arka planda çalışması gereken servis; (6) finans; (7) akıllı telefon; ve bunun gibi. RTS ve gömülü sistemler gibi ezoterik vakalarla sınırlı değildir.
Rex Kerr

103

Ne zaman biri optimizasyon hakkında bir soru sorsa , Michael A. Jackson'tan gelen alıntıyı hatırlatırım

Program Optimizasyonunun İlk Kuralı: Yapmayın.

(Uzmanlar yalnızca!) Programı Optimizasyonu İkinci Kural: Yapmayın henüz .

İngiliz İngilizcesi için düzeltilmiş Wikipedia'dan alıntı. * 8' )

İkinci kuralda örtük olan kodunuzu profillendirmek ve yalnızca fark yaratacak şeyleri optimize etmek için zaman harcamaktır.

Montajda programlama yaparken, babanızın iddiası doğruydu. Ancak bu, metale çoğu insanın bugünlerde programladığından çok daha yakın. Bugün bile kendinizi (profil çıkarmadan) optimize etmeye çalışmak , kodunuzun daha yaygın bir şekilde yaptığınızdan daha yavaş çalışmasına neden olabilir , çünkü ortak yolun modern JIT derleyicileri tarafından optimize edilme olasılığı daha yüksektir .

C'de bile, kod bölümünün nasıl derleneceğine göre optimize edileceği hakkında daha fazla bilgi edinmek için optimizasyonda oldukça iyi olmalısınız.

Ulrich Drepper'ın mükemmel makalesinde, Her Programcının Hafızayla İlgili Bilmeniz Gerekenler adlı kitabında ne hakkında konuştuğunu bilmiyorsanız , muhtemelen kendinizi optimize etmek için çaba harcamak üzeresinizdir. Ancak gazetelerin başlığının aksine (bu aslında David Goldberg'in eşit derecede fantastik bir onurudur. Her Bilgisayar Bilim Adamının Kayan Nokta Aritmetiği Hakkında Bilmeleri Gerekenler ) bu seviyede bir anlayışa sahip olmamanız, sizi farklı bir programlayıcı olarak durdurmanıza gerek bırakmaz. programcı.

isset()vs strlen()içinde PHP

PHP bilmiyorum, bu yüzden ne isset()yapılması gerektiği belli değil . Bağlamdan çıkartabilirim, ancak bu acemi PHP programcılarına benzer şekilde karanlık davranacağı ve daha deneyimli programcıların iki katına çıkmasına neden olabileceği anlamına gelir. Bu, bakımı kabus yapan bir dilin deyimsel kullanım şeklidir.

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

Her optimizasyon gelecekteki bir anti-optimizasyon olma potansiyeline sahiptir , bu nedenle asgari düzeyde tutulması için olası bir kod kokusu olarak kabul edilmelidir.

Kişisel deneyimden bir örnek

Böyle bir anti-optimizasyon örneği olarak, bir zamanlar bir formun koduyla doldurulmuş devasa bir kod tabanını sterilize etmek zorunda kaldım, if x==0 z=0 else z=x*yçünkü birisi kayan nokta çarpımının her zaman bir daldan daha pahalı olacağı varsayımını yaptı . Orijinal hedef mimarisinde bu optimizasyon, kodun daha hızlı bir şekilde çalışmasını sağladı, ancak zaman değişti.

Bu kodu yüksek oranda boru hattına sahip daha modern bir CPU'da kullanmaya çalıştığımızda, performans korkunç derecede kötüydü; z=x*yProgramın yeni mimaride daha hızlı bir şekilde çalışmasını sağlamak için tüm bu kod satırlarını basitleştirmek , anti-optimizasyon tarafından kaybedilen performansı eski haline getirmek .

Genellikle bugün için optimize etmek zorunda olduğumuz sorunlar , 20, hatta 10 yıl önce optimize etmek zorunda olduğumuz sorunlardan çok farklı.

Sonra saat döngüsü başına en fazla işi yapmak konusunda endişeliyiz, şimdi boru hattı yıkamaları, şube yanlış tahminleri ve CPU seviyesinde önbellek kayıpları konusunda endişe etme ihtimalimiz daha yüksek, ancak çok seviyeye geçtikçe kilitler ve işlemler arası iletişim çok daha önemli hale geliyor. süreç ve çok işlemcili mimariler. Drepper'ın makalesi bu sorunların çoğunun anlaşılmasında gerçekten yardımcı olabilir.


3
Boru hattını yıkamak ve önbelleğe almak kaçınmak istediklerinizdir: D Korkunç maliyetleri var. ama yalnızca kodları, onları birçok kez, birçok kez defalarca özgürleştiren kısımlarda.
deadalnix

7
Ekleyeceğim bir şey, derleyicilerin uzun bir yol kat ettiği ve sizin için birçok şeyi optimize edeceği. AFAIK, temiz ve okunaklı kodları zor işlerden daha iyi optimize ediyorlar.
Becuzz

3
Zaman kaybını önleyen gerçek bir mikro-optimizasyon örneği sağlamak için + 1 - ve Michael Jackson'ın bir programcı olduğunu ortaya koydu.
Boz

1
+1 Örnek için. Derleyiciye neden önemsiz dönüşümleri bırakmanız gerektiğini mükemmel bir şekilde göstermektedir.
back2dos,

1
Örnekte @Rex Kerr>, maliyet dallanmadan gelir ve bu da CPU'nun boru hattının akmasına neden olur. Kayan nokta çarpımı da pahalıdır. Daha pahalı olanı, FPU'ya ve kodu çalıştıran CPU'nun boru hattı uzunluğuna bağlıdır. Bu kodun, mevcut işlemciden daha kısa boru hattı ve daha az verimli FPU içeren daha eski CPU'larda daha hızlı çalışması beni şaşırtmazdı.
deadalnix

84
  1. Kod yaz, temiz, özlü, basit ve kendini açıklayıcı.
  2. Darboğazları belirlemek için performans testleri yapın.
  3. Kritik bölümleri optimize edin.

Kural olarak: Kodunuzun% 95'i zamanın% 5'ini çalıştırmaktadır. Kodunuzu profillemeden / kıyaslamadan ve zamanın% 95'inin% 5'inin hangisinin çalıştığını görmeden önce optimizasyonu yapmanın bir anlamı yok.

Her salak mikro optimizasyon yapabilir ve herhangi bir düzgün derleyici / çalışma zamanı sizin için bunu yapar.
İyi kodu optimize etmek önemsizdir. En iyi duruma getirilmiş kod yazma ve daha sonra en iyisi sıkıcı ve en kötüsü sürdürülemez olandan daha iyi hale getirmeye çalışmak.

Eğer varsa ciddi performans için bakım, daha sonra performans kritik kodu için PHP kullanmayın. Darboğazları bulun ve C uzantılarıyla yeniden yazın. PHP kodunuzu şaşırtma noktasının ötesinde mikro-optimize etmek bile size hemen hemen hız vermez.

Şahsen programlamaya başladığımda mikro-optimizasyon yapmaktan çok hoşlandım. Çünkü bu çok açık. Çünkü seni çabucak ödüllendiriyor. Çünkü önemli kararlar almak zorunda değilsin. Bu var mükemmel erteleme araçlarını. Yazılım geliştirmenin gerçekten önemli parçalarından kaçmanızı sağlar: Ölçeklenebilir, esnek, genişletilebilir, sağlam sistemlerin tasarımı.


2
Bana en iyi cevap, dikkat çekici bir şekilde Bugzilla Geliştirici Kılavuzu'nda bulundu: "Okunabilir olmaya çalışmak yerine zeki olmaya çalışıyorsanız, o zaman belki" daha hızlı "şeyler yapmaya çalışıyorsunuzdur?" : var olduğunu bilmeden önce bir sorunu çözmeyin .. Kodunuzun yavaş olduğunu (gerçek, ayrıntılı testlerle) bilmiyorsanız, "daha hızlı" hale getirme konusunda endişelenmeyin. optimizasyon - birçok programcı hiç kimsenin yaşamamış olduğu problemleri sürekli olarak çözmektedir. bugzilla.org/docs/developer.html#general
Marco

7
Genel olarak aynı fikirdeyim - bir satır hariç, "her salak mikro optimize edebileceğini sanıyor " diye itiraf ediyorum ;)
Nim

@Nim: Point Alınan;)
back2dos

26

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

Diğer yorumların çoğuna katılıyorum - C programlarını daha hızlı yapmak için ne kullanılır bugün bunu yapmıyor olabilir - ama dikkate alınması gereken başka ciddi şeyler var: C veya C ++ kullanmalı mıyım? Basit aşırı yüklenmiş operatörleri olan sınıflar, eğer çok kullanırsanız performansı düşürebilir. Önemi var? Bu, uygulamanıza bağlıdır, ancak dikkate bile almazsanız, çok iyi bir programcı değilsinizdir. Bazı millet bunu yaklaşık 2 milisaniye düşünebilir ve reddedebilir, ancak bence çok fazla kişi tam anlamıyla düşünmüyor bile.

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

Başka bir gerçek şu ki, insanlar kodu tekrar kullanmaktan hoşlanıyor ve nerede bitiyorsa yazdığınızdan oldukça farklı olabilir. Birden insanlar umursarlar.

Örnek olarak, PC'de Angry Birds gibi bir şey yazdığınızı veya bir oyun konsolunu yazdığınızı varsayalım. Fizik sisteminizde ve grafik sisteminizde optimizasyonu göz ardı ettiniz - çünkü 2.5 GHz çift çekirdek bu günlerde temelde minimum ve oyununuz yeterince iyi çalışıyor. Ardından akıllı telefonlar gelir ve sizleri portlamak istersiniz. Kahretsin, 600 MHz ARM çekirdeği?

Bir web sitesi düşünün - bir haftasonunda Hot or Not gibi atılan bir şey . Kullanışlı ne veritabanı kullanırsanız kullanın, hızlı bir gelişme ile her şeyi yazın, arkadaşlarınıza bir e-posta göndererek başlatın. Üç ay sonra sunucunuz aşırı yüklenmeden ölüyor ve ölçeklendirmek için yapabileceğiniz hiçbir şey yok. Bu her zaman olur. En büyük web siteleri, yüzlerce kilowatt veya hatta megawatt cinsinden ölçülen elektrik faturalarına sahiptir. Bir düşünün, kod optimizasyonu ile kaydedilecek megawatt var.

Babanın dediği gibi, en azından düşünmelisin . Çoğu kişi masada ne kadar performans olduğunu bile bilmiyor ve "erken optimizasyon" ve "yapma" hakkında hızlı bir quip ile parlıyor. Bunlar iyi programcılar değil.

Bu, bu sitelerdeki popüler bir fikir değil. Güle güle itibar puanları ....


3
Tabii ki, (kafanızın arkasında) dikkate almalı ve buna değmediği sürece, genellikle reddetmelisiniz. Optimizasyonların genellikle kod okunabilirliğini düşürdüğünü ve kodlama ve sürdürme süresini 10 ya da daha fazla bir faktörle artırabileceğini düşünmeniz gerekir. Program CPU yoğun değilse, genellikle gerekli değildir. Derleyicinizin optimizasyonda genellikle sizden daha iyi olduğunu ve optimizasyonlarınızın çoğunun performansınıza zarar vereceğini kabul edin. Optimizasyonlarınızı ve profilinizi test etmek için zaman ayırmaya değmiyorsa, optimize etmek için zaman ayırmaya değmez.
dr jimbob

3
Eğer neden senin Angry Birds örnek tam olarak gösterir değil zamanından önce optimize. Masaüstünden konsoluna ve mobil cihazlara taşırken, bir başkası için yardım etmek yerine, en az üç farklı türde donanım ve optimizasyonla uğraşıyorsunuz. Daha da kötüsü, optimizasyon yapmak kodun anlaşılmasını zorlaştırır, bu nedenle bağlantı noktasını zorlaştırır. Tabii, baştan itibaren verimli algoritmalar seçin, ancak gerçek veriler size her platformda sorunun nerede olduğunu söyleyeceği zaman performans ayarlama aşaması için mikro optimizasyondan tasarruf edin.
Caleb,

@Caleb: Angry Birds örneği, neden belirli donanımlar için en iyi duruma getirilmeyeceğini göstermektedir. Ayrıca, daha genel "C seviyesi" optimizasyonları yapmak için uğraşmadan ve sonra da yakılmadan, tüm bir uygulamayı nasıl oluşturabileceğinizi gösterir. Aslında yanmamış, ama asıl amacının ötesine geçmekte zorlanıyor.
phkahler

25

İlk önce davanıza bakalım: PHP

  • PHP'nin (hem doğası hem de ana uygulama alanı nedeniyle) bu "mikro optimizasyonlar" için endişelenmeniz gereken bir dil olduğunu sanmıyorum. PHP kodu çoğunlukla opcode önbelleklemesi ile optimize edilmiştir.
  • PHP'de yazılmış programlar CPU'ya bağlı değildir, çoğunlukla G / Ç'ye bağlıdırlar, bu nedenle bu optimizasyonlar zamanınıza değmez.
  • Optimize etmeniz gereken herhangi bir şey muhtemelen bir C uzantısına bağlanmalı ve ardından PHP çalışma zamanında dinamik olarak yüklenmelidir.
  • Gördüğünüz gibi, PHP'deki kodumuzu mikro-optimizasyonla teşvik etmiyoruz - diğer yandan, eğer PHP PHP kodunu daha okunaklı ve bakımını yapmak için harcıyorsanız - bu size daha fazla temettü kazandırır.

Genel olarak,

Kodumu Python veya Ruby gibi dinamik bir dilde optimize etmek için "TOOOOO" 'ya çok fazla zaman harcamam - çünkü CPU yoğun sayı-sıkma görevleri için tasarlanmamıştır. Gerçek dünyadaki durumun ayrıntılı bir şekilde (okunması ve bakımı kolay olan) modellenmesinin - ifade olarak adlandırılan - hızdan daha önemli olduğu farklı problem sınıflarını çözerler . Hız ana kaygı olsaydı, her şeyden önce dinamik olmazlardı.

Derlenmiş programlar için (C ++, Java), optimizasyon daha önemlidir. Fakat orada da, ilk önce yazdığınız programın niteliğine / etki alanına / amacına bakmalısınız. Ayrıca, bu optimizasyondan elde edilen kazanımlara karşı mikro-optimizasyon süresini dikkatle tartmalısınız. Daha fazla optimizasyona ihtiyacınız varsa aşağı doğru bir adım atmayı düşünebilirsiniz - ve kodunuzun bu parçalarını assembler içinde kodlayın.

Öyleyse, asıl sorunuza cevap vermek için - "Kodlama sırasında mikro optimizasyon önemli midir?" -- Cevap, duruma bağlı --

  • Ne tür bir şey yapıyorsunuz: uygulama alanı, karmaşıklık?
  • Mikrosaniye hızındaki gelişmeler programınız için GERÇEKTEN önemli midir?
  • Ne tür bir optimizasyon en kazançlı olacak? Her zaman kod optimizasyonu olmayabilir, ancak harici bir şey olabilir.
  • Mikro optimizasyona yatırım yaptığınız zamandan ne kadar “iyilik” (hız olarak) elde ediyorsunuz?
  • Donanımı, RAM ve işlemciyi değiştirerek, kod paralelini uygulayarak veya dağıtılmış bir sistemde daha iyi hızlara ulaşılabilir mi?

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


18

Mikro optimizasyon olduğunu söyleyen birçok cevap var gibi görünüyor.

Her şey değişmeyecek - performans, zaman, maliyet, çaba, okunabilirlik / bakım kolaylığı vb.

Fakat iyi okunurluk etkisinin olmadığı bazı optimizasyonlar olduğunu biliyorum ve sadece eğlence için yapmayı seviyorum. Bazı okul ödevlerime baktım (hepsi hıza dayalıydı), aşağıdaki 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 güzel

if (shouldDoThis() && counter < X ) 

Bu şekilde kodunuzu "hızlandırmak" için birkaç yol vardır ve fark genellikle ihmal edilebilir (her zaman olmamakla birlikte), ancak böyle yazarsam daha iyi hissediyorum.

Birisi bunu gerçekten bir optimizasyon olarak görüp görmediğini bilmiyorum ama bir programcının kodlarını yazarken bunları bilmesi ve dikkate alması gerektiğini düşünüyorum.


2
Bu özel durum için önemli olmayabilir . Ancak ben öyle düşünüyorum çok o zaman, böylece bunlar gibi optimizasyonlar tanıyabilmek için önemli yapar olsun, gereksiz zaman profil ve aslında sonra optimize harcamak gerekmez.
tskuzzy

4
Bu çok tehlikeli bir örnek. Bir optimizasyon gerektiğini asla davranışını değiştirmek . Bunun cheap() && expensive()bir optimizasyon olduğunu öne sürmek bile expensive () && cheap(), insanları yarattığı önemli anlamsal değişime bakılmaksızın bir diğerini kör bir şekilde ikame etmeye davet eder ( &&kısa devre operatörünün bulunduğu dillerde ).
Mark Booth,

5
İşlevlerin yan etkileri yoksa, eşdeğerdir ve biri daha hızlıdır. Yan etkileri varsa, kişi ilk önce böyle bir kod yazmamalı. Bunun alışkanlık dışı yapılması gereken bir şey olduğunu bile söyleyebilirim - aslında davranışları değiştirmezse.
phkahler

3
@MarkBooth Burada phkahler ile aynı fikirdeyim, bu fonksiyonlardan hiçbirisinin yan etkileri olmamalı! Bir if ifadesindeki condionos sırası, programın sonucunu etkilememelidir. Benim örneğim if (x<100 && isPrime(x)), daha net yapmak için, daha iyi yazılmış olacaktı .
zidarsk8

1
@ zidarsk8 - Bir optimizasyon , yürütme hızından başka bir şeyi değiştirirse , bir optimizasyon değildir . Programcılar olarak genellikle pragmatik olmak zorundayız ve bazen kısa devre operatörü ile kullanılan tüm fonksiyonların saf olduğunu garanti edemeyiz - özellikle de kodumuz üzerinde kontrolümüz olmayan üçüncü taraf kütüphaneleri çağırdığında. Bu durumda deneyimsiz programcıların optimizasyon adına hatalar koyma konusunda teşvik edilmemesine dikkat etmeniz gerekir .
Mark Booth,

11

Kariyerimin başlarında, "mikro-optimizasyon yapma" gibi battaniye ifadeleri bir sürü kafa karışıklığına yol açtı. Her şey olağanüstü; Bu nedenle, insanların sebebi, "bunu yapmaktan ziyade" en iyi uygulama "dır.

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

  • Patronuma, binlerce dolarlık yeni bir SQL Server sürümü satın alma fikri üzerine satış yapmak.
  • Geliştiriciler yeni teknoloji öğrenme fikri üzerine satıyorum.

Tecrübelerden biliyorum ki bu olmayacak. Böylece istifa edebilir, sonuna kadar strese girebilir ya da en iyi uygulamayı izleyemezdim.

Genel sonucu etkileyen kararların arkasında siyasi, teknik ve parasal düşünceler var. Bir karar verirken bu gerçeği unutmayın ve savaşlarınızı akıllıca seçin.

" Her şey için bir mevsim, cennetteki her aktivite için bir zaman. "


1
BTW, Dapper'ı satır içi SQL'e alternatif bir mikro ORM olarak kullanabilirsiniz .
Dan

2
LINQ and Entity Framework should be used in lieu of inline SQL- Gerçekten bir şeyi optimize etmek için satır içi SQL'e ihtiyaç duyana kadar; EF'in ürettiği SQL her zaman optimum değildir.
Robert Harvey,

1
Patronun (mevcut olabilir başka ne ya) SQL 2K8 lisans ücretleri hakkında endişe ise FWIW, sen işaret aşımı gerektiğini bunun EOL geliyor-up olacak yaşta olduğunu ÇOK (zaten değilse) yakında
warren

@ warren - Bazı şirketler böyle şeyleri dikkate almazlar. Bazıları için, eğer hala "çalışıyorsa" yükseltme yapmazlar. İşle, sunucu hala çalışıyor demek istiyorum. Şimdiden EF ile destek eksikliği görüyoruz. Bu sadece onları para harcamaya ikna etmek için yeterli değil.
P.Brian.Mackey

1
Bilirsiniz, SQL 2000 ile EF kullanabilirsiniz. Tasarımcı çalışmıyor, ancak gerçek varlık çerçevesi SQL 2000'i destekliyor. Tasarımcı sınırlamasını aşmak için sql 2008'de aynı şema ile yerel bir veritabanı oluşturabilirsiniz. sql 2000 veritabanı olarak, tasarımcıyı tüm sınıfları üretecek şekilde işaretleyin, ardından .edmx dosyasına gidin ve hedef veritabanı sürümünü 2000 olarak değiştirin ve sql server 2000 veritabanınızdaki bağlantı dizesini işaretleyin. En iyi çözüm değil, ancak yükseltme yapamıyorsanız çalışır.
Neil

8

Bu her zaman bir tradeoff.

İlk olarak, bilgisayar endüstrisi sonunda parayla ilgilidir. Bir geliştirici olarak yapmanız gereken şey, müşteri için değer üretmektir, bu yüzden para kazanırsınız (bu bir aşırı basitleştirmedir, ancak asıl mesele burada).

Geliştirici zaman paraya mal olur. Makine gücü de paralıdır. Genellikle, bu ikinci maliyet birincisinden çok daha düşüktür. Bu yüzden, okunabilir bir koda ve sürdürülebilir koda sahip olmak için bu büyüktür, geliştirici zamanının çoğunu değer sunmak için harcayabilir.

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

İkincisi, büyük bir projedeki mikro optimizasyon, bakımını / gelişmesini zorlaştırır ve zorlaştırır. Bununla ilgili sorun, evrimleşerken, başka bir optimizasyon yapmak artık 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 seti büyüdüğünde yapabileceğiniz herhangi bir mikro-optimizasyonun üstesinden geleceğinden optimizasyon çoğu zaman önemsizdir. Ne yazık ki, mikro optimizasyon kodunuzu korumak / geliştirmek için zorlaştırdığından, optimizasyon işlemi yapmak daha zor olabilir.

Bazen, değer bu optimizasyondadır (video oyunlarında veya bir uçağın otopilotunda olduğu gibi kritik gecikme programlarını düşünün). Ancak bunun kanıtlanması gerekiyor. Genellikle programınız çoğu zaman sınırlı bir kod bölümünde geçirir. Ne tür mikro optimizasyon yaparsanız yapın, darboğazı tespit etmeden programlarınızı hiçbir zaman çok daha hızlı bir şekilde elde etmeyeceksiniz ve bu kısımda çalışamazsınız.

Sorunuzu yaptığınız gibi sormak, sorunu gerçek bir programda kıyaslamadığınızı göstermiştir. Bu durumda, hile yapabilir ve daha hızlı olup olmadığına dikkat edebilirsiniz. Yani herhangi bir problem yaşamadan önce bunu soruyordunuz. Sorunun olduğu yer burası. Optimizasyon problemini yanlış şekilde ele alıyordun.

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. O zaman, programınızın parçaları bir başkası için yeterince soyutsa, her şeyi mahvetmeden bir mikro-optimize edebilirsiniz. Bu, arayüzünüzün güvenilir olması için yeterince uzun süre çalışmasını gerektirir.


"Her zaman bir tradeoff var". Doğru, bir değişkeni azaltmak , program değişme eğrisindeyse , diğerini artıracaktır . Tecrübelerime göre, çoğu program tradeoff eğrisinin hiçbir yerinde bulunmuyor ve her iki değişkenin de azalması için yeterli alan var.
Mike Dunlavey

+1 bakım ve gelişim, mikro optimizasyondan daha değerlidir. Bilgisayar endüstrisinin sadece paradan daha fazlası olduğuna emin olmama rağmen? Örneğin, açık kaynak, eğitim, inovasyon, yönetişim, topluluk vb. Köklerinde para bulunabileceğinden eminim, ama bu çoğu şey için geçerlidir.
Boz

@ Boz kay> Bu kısmen doğrudur. Öncelikle, patronunuz ve velayetiniz çoğunlukla, tomurcuklanma hakkında bir şey bilmez ve paraya değer verir. Bazı açık kaynaklı araçların tanıtımını yapmak istiyorsanız, onlara şirketin markasını nasıl geliştireceğini veya geliştirme maliyetlerini nasıl azaltacağını söylemeniz gerekir. Ayrıca, geliştiricileri mutlu etmek, şirketinizde başarılı olmanın bir yoludur. İyi gelişim para kazanır (çoğunlukla kalite ve yenilikçilik sağlar). Sonunda, para anahtardır. Ve linux bilgisayarımdan harika bir özgür yazılım destekçisi olduğumu yazıyorum. Aynı şey eğitim için de geçerli.
deadalnix,

8

Performans bir özelliktir

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

Bununla birlikte, gerekene kadar mikro optimizasyona odaklanmayın. Yapabileceğiniz daha uygun maliyetli optimizasyonlar var. Mimariye odaklanın, kodu değil. Yavaş yavaş yaptığım web sitelerinin çoğu, yalnızca performansı olumsuz etkilemekle kalmayıp aynı zamanda derine gömülmüş ve düzeltilmesi zor olan yüksek düzeyde sorunlara (gereksiz web servis katmanı, zayıf veritabanı tasarımı, aşırı karmaşık mimariler) sahipti.

Bir web sitesi oluştururken, müşteri tarafı kodunuz ve veritabanı mantığınız, sunucu yan kodunuzdan daha fazla performans sorununa neden olabilir. Yine de her şey gibi, performans sorunlarınız varsa, kodunuzu daha iyi profillendirebilirseniz ve bunları daha erken bulabilirsiniz.


7

Geliştirici süresi bilgisayar saatinden daha pahalı. Genelde optimize etmek istediğiniz şey budur. Fakat:

  • Mikro optimizasyon ve algoritmik karmaşıklık arasında bir fark var. Doğru algoritmayı kullandığınızdan emin olmak için yeterli zaman ayırın .
  • Doğru soruyu sorduğundan emin ol select (select count(*) from foo) >= 1, aynı şey değil select exists(select 1 from foo).
  • bazı dil deyimleri popülerdir çünkü daha hızlıdırlar, dilin akıcı kullanıcıları onlara aşina olacağından bunları kullanmak sorun değil. (örneğiniz iyi bir örnektir).

7

Neyi optimize etmek istiyorsunuz?

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

"Optimize etmek" her zaman kodun olabildiğince hızlı çalışmasını sağlamak anlamına gelmez. Bir şeyi yapmanın en hızlı yolunu bulmanın önemli olduğu zamanlar vardır, ancak çoğu kodda o kadar da yaygın değildir. Kullanıcılar 50 ile 100 mikrosaniye arasındaki farkı fark edemezlerse, kodda yalnızca arada sırada çalışacak olan ikisi arasında etkili bir fark olmaz. İşte bir örnek:

Kullanıcının girişinin uzunluğunu ve bu uzunluğun ardışık iki tuş vuruşu arasındaki süreden çok daha küçük olduğunu belirlemek için iki rutinden birini geçen süreyi sürekli olarak güncellemeniz gerekirse kullan. Öte yandan, bir milyar dizenin uzunluğunu belirlemeniz gerekirse, muhtemelen farklı rutinler arasındaki performans farklarına yakından bakmak isteyeceksiniz. İlk durumda, anlaşılması ve doğrulanması kolay bir kod yazmayı tercih edebilirsiniz; İkinci durumda, hız için okunabilirliği takas etmeye istekli olabilirsiniz.

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öylemenin genellikle zor olduğu kadar karmaşıktır; profil oluşturma , doğru kodu optimize etmenize yardımcı olur ve daha sonra yaptığınız optimizasyonların gerçekten işe yaradığını gösterir.

Baban ne zaman emekli oldu ya da ne tür bir programlama yaptığını söylemedin, ama tepkisi şaşırtıcı değil. Tarihsel olarak, bellek, ikincil depolama ve hesaplama süresi pahalı ve bazen çok pahalıydı. Bu günlerde, tüm bunlar programcının zamanına göre çok ucuz oldu. Aynı zamanda, işlemciler ve derleyiciler, kodları, programcıların asla eşleştiremeyeceği şekilde optimize etmek haline geldi. Programcıların burada birkaç makine talimatını almak için küçük numaralar kullandığı günler ve çoğu zaman geride kaldı.


1
+1 Son birkaç yılda mobil cihazların tekrar kod optimizasyonuna bağımlı hale geldiğinden bahsetmiyorum. En iyi duruma getirilmiş kod yazmayan veya en azından CPU yoğun uygulamalarının bir mobil cihazda sorunsuz çalışmasını sağlamakta zorlanabileceğini düşünen biri.
Styler

Olası optimizasyonlar listene çok benzeyip +1. Meclis / fortran'ı kullandı
Boz

@Styler: mobil cihazlarda GB belleği olan dört çekirdekli işlemciye sahip olmak uzun sürmez, zaten çift çekirdekli akıllı telefonlarımız var.
Yalan Ryan

@Lie Ryan: evet bu doğru, ancak çoğu öncü gibi tahta teknelerle seyahat etmek zorunda kaldılar;)
Styler

7

Kod yazarken mikro optimize etmek önemli değildir. Optimizasyon, bir profiler yardımı ile yapılmalı ve kodun önemli olduğu yerlerde optimizasyon yapılmalıdır.

ANCAK , bir programcı gereken kod yazarken belli ki aptal şeyler yapıyor kaçının.

Örneğin, bir döngü içinde tekrarlanan pahalı işlemleri yapmayın. Değeri döngünün dışındaki bir değişkende saklayın ve bunu kullanın. Dize karşılaştırmaları ya da sık sık denilen bir fonksiyonda tekrar tekrar regex yapmak gibi şeyler yapmayın, bir seviyeye yükseldiğinizde, karşılaştırmayı yapın ve bir tam sayı veya fonksiyon referansı veya türetilmiş bir sınıfa dönüştürün.

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


Soru düzenlememde daha net olmam gerektiğinin farkına vardım, aynı şeyi söylüyordum gerçekten - Ben bunu güncelledim.
Boz

7

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

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

Bu nedenle insanlar her zaman programınızın toplam çalışma süresinin yüzde birkaçından fazlasını işgal etmeyen parçalarının optimize edilmesinin değmeyeceğini söylüyor. Ama bu sadece daha genel bir ilkenin özel bir hali. Amdahl kanunu, tüm programı iki kat daha hızlı çalıştırmanız gerekirse, her parçayı ortalama% 50 hızlandırmanız gerektiğini söyler . Yirmi gigabayt veriyi işlemeniz gerekirse, bunun yirmi gigabayt'ı diskten okumak için harcadığınız süreden daha hızlı gitmesinin yalnızca iki yolu olduğunu söyler: daha hızlı bir disk elde etmek veya verileri küçültmek.

Peki, Amdahl yasası mikro-optimizasyonlar hakkında ne diyor? Tahtanın karşısına başvururlarsa belki buna değeceklerini söylüyor. Programınızdaki her işlevin çalışma süresinin yüzde birini tıraş ederseniz, tebrikler! Programı yüzde bir hızlandırdın. Bu yapmaya değer miydi? Derleyici bir adam olarak, bunu yapan bir optimizasyon bulmaktan memnun olurum, fakat elle yapıyorsanız daha büyük bir şey aradığımı söyleyebilirim.


1
Amdahl fiyat teklifi için +1, ancak "tüm programı iki kat daha hızlı çalıştırmak için her parçayı hızlandırmanız gerekir" ile aynı fikirdeyim. Aslına bakarsan hiçbir "parçayı" hızlandırmadığını söyleyebilirim. Aksine, gereksiz bir iş bulursunuz ve onu ortadan kaldırırsınız. Program bir oyuncaktan daha büyük bir şeyse, özellikle işlev çağrıları. Performansla ilgili yaygın düşüncenin çoğu, çağrı ağacının (tek bir yönerge olabilir) tüm gereksiz kollarını bulmanın ve onları atlatmanın önemini tamamen görmezden geliyor gibi görünmektedir.
Mike Dunlavey

Şeytanın orada "ortalama" yazıyor. Matematiksel olarak, bir programı% 50 hızlandırmak için her parçanın ortalama % 50 hızlandırılması gerekir . Şimdi, programı çalışma zamanının% 75'ini,% 25'ini alan başka bir işi ikiye bölerseniz ve önceki 3x'i hızlandırabilirseniz, bu ikinci iş için hiçbir şey yapmamış olmanıza rağmen genel olarak% 50 verir. Ancak en yaygın durum, çalışma süresinin% 5'inden daha azını alan düzinelerce "iş" olmasıdır - ve sonra çoğunu hızlandırmanız veya ondan kurtulmanız gerekir.
zwol

Bence daha da yaygın bir dava var. Zamanın% 50'sini alan bir "iş" var, ancak buna gerçekten ihtiyacınız yok , bu yüzden tamamen kaldırırsınız, toplam süreyi o kadar azaltır, sonra tekrarlayın. Bunun kabullenmenin zor olduğunu biliyorum - programlar, (gereksiz yere) tamamen gereksiz olan şeyleri yaparak zamanın büyük bir kısmını harcayabilir. Ama işte benim kanonik örneğim .
Mike Dunlavey,

6

Gelişimin hangi aşamasında olduğunuza bağlı, başlangıçta bir şeyler yazmaya başladığınızda, mikro optimizasyonlardan daha iyi performans elde edeceğinizden daha iyi performans elde edeceğiniz için mikro optimizasyonlar dikkate alınmamalıdır. Ayrıca, zamana duyarlı uygulamalar, genel işletme uygulamalarına göre mikro optimizasyon hususlarından daha fazla fayda göreceğinden, geliştirmekte olduğunuzu düşünün.

Yazılımı test ediyor ve genişletiyorsanız, mikro optimizasyonlar muhtemelen size zarar verecek, kodun okunmasını zorlaştıracak ve hatta düzeltilmesi gereken başka bir şeyle birlikte düzeltilmesi gereken kendi benzersiz hata setlerini tanıtabileceklerdir.

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

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

Bu soruların hepsi yanıtlandıysa ve hala performans sorunlarınız varsa, o zaman kodda mikro optimizasyonlar kullanmaya başlamanın zamanı olabilir, ancak diğer değişikliklerin (yani daha iyi kod, daha iyi algoritma, vb.) Sizi netleştireceği ihtimalleri Bir mikro-optimizasyondan daha fazla performans kazancı olacaktır.


5

Uygulama hızı, 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. Neredeyse tüm durumlarda, kodun okunabilmesi için kodun okunabilir olması gerekir. Okunabilirliğin tehlikeye girebileceği tek zaman, hızın temel bir gereklilik olduğu zamandır. Kodu tam okunabilirlik / bakım yapılabilirlikten daha hızlı hale getirme zorunluluğu neredeyse hiç uygulanabilir değildir, ancak uygulanacağı belirli durumlar vardır. Hatırlanması gereken en önemli şey, mikro-optimize edilmiş kodun genellikle sahte kod olmasıdır, bu nedenle, bir yerde tanımlanmış bir gereklilik olmadıkça, sorunu çözmek için neredeyse her zaman yanlış yoldur. Örneğin, kullanıcı CRUD işlemlerinde .5 saniye ile 1 saniye arasında yürütme süreleri arasındaki farkı hemen hemen hiç fark etmeyecek, Böylece, 0,5 saniyeye ulaşmak için bir montaj-birlikte çalışma-hackfest'e girmenize gerek kalmaz. Evet, çalışmak için bir helikopter uçurabilirim ve 10 kat daha hızlı olur, ama fiyatı ve helikopterin uçması çok zor olduğu için yapmıyorum.Gereksiz yere mikro-optimizasyon yaptığınız zaman, tam olarak yaptığınız budur: gereksiz bir hedefe ulaşmak için gereksiz karmaşıklık ve maliyet.


5

Bir kısıtlamaya bastığınızda mikro optimizasyon önemlidir. Önemsediğiniz şey hafıza olabilir, işlem olabilir, gecikme olabilir veya güç tüketimi olabilir. Bunların sistem düzeyinde özellikler olduğuna dikkat edin; her işlevi her şekilde en iyi duruma getirmenize (ve yapamamasına) gerek yoktur.

Gömülü sistemlerde mikro optimizasyona daha çok ihtiyaç duyulur, çünkü kısıtlamalar daha kolay etkilenir. Ancak, orada bile mikro optimizasyon sadece şimdiye kadar alır; Kötü bir tasarımdan çıkış yolunuzu mikro-optimize edemezsiniz. Bir sistemdeki iyi tasarımın amacı, sistem hakkında bir bütün olarak sebep olabilirsiniz. Mikro optimizasyon gerektiren bileşenler, sistemin tasarımından ödün vermeyecek şekilde özenle gösterilmeli ve optimize edilmelidir.

Bugün küçük "gömülü" sistemlerin, eski yılların Vaxen veya PDP- 11'lerine oldukça yakın olabileceğine dikkat edin , bu nedenle bu sorunlar daha yaygındı. Modern genel ticari hesaplama yapan modern bir genel amaçlı sistemde, mikro-optimizasyon nadirdir. Bu muhtemelen babanın neden pozisyon aldığını gösteriyor.

Ancak, nanosaniye, milisaniye, saniye ya da saatlerle uğraşmanız önemli değil; sorunlar aynı. Sistem bağlamında ve neyi başarmaya çalıştığınız bağlamda değerlendirilmeleri gerekir.

Bu, mikro optimizasyonun gerekli olduğu bir durum için Stack Overflow'ta cevapladığım son sorudan bir örnek : Gömülü bir sistem için açık kaynaklı video kodlayıcılar .


4

Mikro optimizasyonla ilgili en büyük sorun, bakımı daha zor bir kod yazmaya yönlendirmesidir.

Başka bir sorun bilgisayar yapılandırmasına bağlı olarak bazen mikro optimizasyonunuz, 'optimizasyondan' daha kötü bir performansa sahip olabilir.

Pek çok mikro-optimizasyon yapmak sizi gerçekten önemli olmayan bir şeye karşı mücadele ederken çok fazla zaman tüketir.

Daha iyi bir yaklaşım, daha temiz bir kod yaparak, bakımı daha kolay ve performans sorunlarıyla karşılaşırsanız, kodunuzu gerçekten yavaşlatan şeyin ne olduğunu bulmak için bir profil kullanmaktır. Ve tam olarak neyin kötü olduğunu bilmek, onu düzeltebilirsiniz.

Mikro optimizasyon yapmamak aptal kod yazmak için bahane değil demiyorum.


4

Milisaniye hakkında endişelenmeye başlarsanız, PHP'den vazgeçmeli ve bunun yerine C veya Assembly kullanmalısınız. Bunu yapmak istemem değil, sadece bu sayıları tartışmak ve bir betik dili kullanmak hiç mantıklı gelmiyor. Kodunuz zaten bu komutla yineleniyor mu?

Buradaki çevresel faktörler söz konusu değil, bu sunucular yine de 7/24 çalışıyor ve gerçekten bir şeyi işliyorlarsa, eğer gerçekten çok uzun bir süredir çalışan bir görevse önemli olacak.

Büyük olasılıkla ofisinizdeki ışık ve hepimizin soru ve cevaplarını yazarken bilgisayarlarımızın kullandığı enerji, uygulamalarınız için makul bir şekilde uygulayabileceğiniz her türlü mikro optimizasyondan çok daha fazla enerji harcadı.


+1 ışığı söndürmek veya soruları yanıtlamamak.
Boz

4

Görev için en iyi, basit algoritmayı seçmelisiniz. Basit olmasının nedeni, kodu okunabilir tutmaktır. En iyi olmasının sebebi, kötü çalışma zamanı özellikleriyle başlamaktan kaçınmaktır. Büyük veri setlerine sahip olduğunuzu bildiğiniz zaman, BubbleSort'u körlemeyin. Bununla birlikte, ara sıra 10 element için sorun yoktur.

Daha sonra, profil numaraları en iyi, basit algoritma seçiminizin yeterince iyi olmadığını gösteriyorsa, optimizasyonu başlatabilirsiniz (bu genellikle okunabilirliğin maliyetidir).


BubbleSort, verileriniz nihai hedeflerinden çok uzakta olmayan yalnızca birkaç başıboş öğeyle sıralanırsa, aslında quicksort veya mergesort'tan daha iyi olabilir. Bununla birlikte, diğer tüm görevler için, programlama dilinizin size sağladığı yerleşik sıralama işlevini kullanmalısınız; başlamanın en kolay yolu (ve çoğu dilde yerleşik sıralama işlevi iyi performans gösteriyor). KÖTÜ TAVSİYE:, start out with bad runtime characteristickasıtlı olarak kötü bir çalışma zamanı özelliği ile başlama.
Lie Ryan,

@Lie, verilerinizin neredeyse sıralandığını ve bundan önce bubblesort kullanabileceğini BİLENEN BİLİYORUN, algoritmanızı tam olarak seçmezsiniz ... Ayrıca yazım aracını işaret ettiğiniz için teşekkürler.

4

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

Kod, bir noktaya kadar, her zaman şu anda olduğundan daha hızlı olabilir. Belirli bir yonga ile elle paketleme düzeneği olmadıkça, her zaman optimizasyon ile kazanılacak bir şey var. Ancak, yaptığınız her şey için elle paketleme düzeneği olmak istemediğiniz sürece, bir kez karşılaştığınızda, "yeter" diyen ve hala göze batan bir performans emici göze başlamış olsa bile optimizasyonun durması gereken nicel bir hedef olmalı. sen yüzüne.

Güzel, zarif, çok yüksek performanslı kod işe yaramazsa işe yaramaz (ve "iş" derken, beklenen tüm girdiler verilen beklenen çıktıyı üretiyorum). Bu nedenle, çalışan kod üretmek HER ZAMAN birinci öncelik olmalıdır. Çalıştıktan sonra performansı değerlendiriyorsunuz ve eğer eksikse, daha iyi hale getirmenin yollarını, yeterince iyi olduğu noktaya kadar ararsınız.

Performansı etkileyecek karar vermeniz gereken bazı şeyler var; Bu çözümü uygulamak için hangi dili / çalışma zamanını kullanacağınız gibi çok temel kararlar. Bunların çoğu, bir yöntemi diğerine çağırmaktan çok, büyüklük sırasına göre performansı etkileyecektir. Dürüst olmak gerekirse, PHP, bir komut dosyası dili olarak zaten bir performans hedefidir, ancak C / C ++ ile aşağıdan yukarıya kodlanmış siteler kurulduğundan, muhtemelen seçeceğ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. Okuduklarınızı optimize etmek ve sabit diske, seri bağlantı noktalarına, ağ borularına vb. Yazmak. Programın çalışma süresini genellikle, G / Ç işlemlerinin arkasındaki algoritmalar verimli olsa bile, programın çalışma süresini büyük ölçüde düzenleyecektir. Ondan sonra, algoritmanın kendisinin Big-O karmaşıklığını azaltın ve daha sonra kesinlikle gerekiyorsa, daha ucuz yöntem çağrıları seçip düşük seviyelerde diğer ezoterik kararlar alarak "mikro-optimizasyon" yapabilirsiniz.


2
+1 Çalışan kod üretmek HER ZAMAN birinci öncelik olmalıdır.
Boz

2
@Keith, aslında Knuth önce bunu söyledi ve bundan biraz daha fazlasını söyledi.

"Çalışmasını sağla, sonra çalışması gerektiği kadar hızlı çalışmasını sağla", Anon.
John Saunders

1
Aslında din tüm kötülüklerin köküdür, fakat ben dalıyorum.
Thomas Eding,

4

Babanın emekli bir programcı olduğunu söylüyorsun. Ana bilgisayarda çalışan programcılar performans konusunda çok endişeliydiler. Ana bilgisayarlarının donanım başına kısıtlı olduğu ve kullanıcı başına 64 KB belleğe sahip olduğu bir ABD Donanması etkinliği okuduğumu hatırlayabilirim. Bu programlama dünyasında yapabildiğiniz her küçük parçayı bulmak zorundasınız.

Artık işler çok farklı ve programcıların çoğunun mikro optimizasyonlar için çok endişelenmesine gerek yok. Bununla birlikte, gömülü sistemler programcıları hala yapıyor ve veritabanı kullanıcılarının hala iyimser kod kullanmaları gerekiyor.


3

Kodun ne yaptığı hakkında kesin olarak net olması için yazılmalıdır. Sonra, eğer ve ancak eğer çok yavaş geri dönüp onu hızlandırabilirsiniz. Kod, daha sonra anlaşılırsa daha hızlı olacak şekilde değiştirilebilir - ancak anlaşılırsa hızlı olması için açık olması için iyi şanslar.


3

Aşağıdaki durumlarda önemlidir:

1) Birinin hayatı kodunuza bağlıdır. Birisinin kalp atış hızı monitöründe çalıştırmak için 25ms alan bir işlev muhtemelen kötü bir fikirdir.

Şahsen iki yönlü bir yaklaşım benimsem - okunabilirliği etkilemeyebilecek yapabileceğiniz mikro optimizasyonlar var - açıkçası bunları kullanmak istiyorsunuz. Ancak okunabilirliği etkilerse, uzak durun - çok fazla fayda elde edemezsiniz ve aslında uzun vadede hata ayıklamanız daha uzun sürebilir.


2
Örneğinizde sadece birkaç küçük nokta: Kalp atış hızı monitöründe 25 ms alan bir işlev, gerekli yanıt süresinde başka gerekli görevler gerçekleştirilebildiği sürece sorun olmaz. Kesmeler bunun için iyidir. Ve 25ms gecikme, yalnızca insani tüketim ekranını güncellemek için gerçek dünya olaylarını izleyen bir şey için büyük olasılıkla bir sorun değil.
janm

3

Kodlamada mikro optimizasyon önemli midir?

Hayır, JVM ve .NET gibi platformların bulunduğu ve kodun bir sanal makine için yazıldığı ve bu nedenle yürütmeyi optimize etmeye çalıştığı için, geliştiricinin masaüstünde optimal olanın sunucuda aynı olması gerektiği kadar iyi çalışmayabilir. Bu üst düzey yazılım parçalarının bazılarının donanımdan ne kadar uzakta olduklarına bakın burada başka bir nokta için. Dikkate alınacak bir şey varsa donanım çeşitliliği verilir, yeni bir model muhtemelen bir yıldan daha kısa bir sürede ortaya çıkacaksa, bir CPU veya GPU gibi belirli yongalar için kodu optimize etmek ne kadar gerçekçidir?

Burada göz önünde bulundurulması gereken bir diğer soru, ölçüt olarak ölçülen performanstır: Yürütme hızı, yürütmede kullanılan bellek, yeni özelliklerin geliştirilme hızı, bir sunucudaki kod tabanının derlenmiş veya derlenmiş biçimlerde boyutu, ölçeklenebilirlik, bakım kolaylığı, vb. .? Eğer yeterince geniş bir şekilde ele alınırsa, soru önemsiz hale gelir, ancak performansı ne kadar geniş bir şekilde ölçmek istediğinizi tam olarak anlayamayacağınızdan emin değilim, bir şekilde ölçülebildiği sürece neredeyse her şey olabilir.


Bazı mikro-optimizasyonlar işe yarayabilir ve bazıları işe yaramayabilir; bu, yeni özellikler veya hataların giderilmesi gibi daha yüksek öncelikli olarak görülen diğer işlerle karşılaştırıldığında bu işi yapmanın ne kadar değerli olduğunu merak edebilir. Diğer soru, donanım veya yazılım yükseltmesinin de bu optimizasyonların bazılarını bozup bozmayacağıdır.


1
Eğer unutmayın olabilir kesinlikle JVM ve .NET gibi platformlarda mikro optimizasyonlar, sadece biraz farklı şekillerde yoktur. Ancak aynı, eski, basit C derleyicisini daha modern, yüksek düzeyde iyileştirici bir derleyici ile karşılaştırırsanız geçerlidir: Kullanıcının yapabileceği optimizasyonlar farklı görünecektir.
Joachim Sauer

1

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

Aynı işi yapmanın iki yolu varsa, biri diğerinden daha hızlı ve her 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 sebep yoktur. Ve hatta belgelenmesi kolaydır: algoritma adını verin, herkes Google'a girebilecek ve nasıl çalıştığı hakkında daha fazla bilgi bulabilecek.

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

Bunları kullanarak programınız hala bu performansa sahip olmasa bile, onları mikro-optimize etmeyi düşünebilirsiniz. Ve mikro-optimizasyon yapabilmek için dili gerçekten bilmek zorundasınız.

Ve her zaman donanıma biraz daha fazla para harcamak için yer vardır. Donanım ucuz, programcılar pahalı . Ne zaman donanım satın alabileceğinizin optimizasyonunu yaparak çok fazla zaman / para harcamayın.


1

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

Anlamsız mikro optimizasyonlar hakkında makale :

Çoğumuz olarak, baskıyı yankı ile değiştirmek, ++ $ i $ i ++ ile ya da tekli tırnaklarla çift tırnak gibi anlamsız mikro optimizasyonlarla ilgili blog yazılarını okumaktan yoruldum. Neden? Çünkü zamanın% 99,999999'u alakasız. Neden? Çünkü zamanın% 99,99'u APC gibi bir PHP hızlandırıcısı kurmanız ya da bu eksik dizinleri veritabanı sütunlarınıza eklemeniz ya da ana sayfada sahip olduğunuz 1000 veritabanı talebinden kaçınmaya çalışmalısınız.

print bir şey daha kullanır çünkü gerçekte bir şey döndürür. Echo'nun baskıdan daha hızlı olduğu sonucuna varabiliriz. Fakat bir opcode hiçbir şeye mal olmaz, gerçekten hiçbir şeye mal olmaz.

Yeni bir WordPress kurulumunda denedim. Komut dizisi bilgisayarımda "Bus Error" ile bitmeden önce duruyor, ancak opcod sayısı zaten 2.3 milyondan fazlaydı. Yeterince söylendi.

Bu nedenle çoğu durumda mikro-optimizasyon milyonlarca işlemden tasarruf sağlar, ancak okunabilirliği daha da kötüleştirir.


1

Diğer cevaplar doğru. Ancak , dilin / çerçeve yapılarının davranışının bir anlayışını yansıtan erken optimizasyon / mikro optimizasyon ve yazma kodunu ayırt etmek zorunda olan başka bir nokta daha ekleyeceğim (üzgünüm, sonuncusu için bir kelime bulamadım) . Sonuncusu bir olduğunu iyi kodlama uygulaması ve bir genel yapmalıdır!

Açıklayacağım. Kötü optimizasyon (okuma erken / mikro optimizasyon) gerçekten darboğazlar olup olmadıklarını bilmek için profil oluşturmadan kod bölümlerini optimize ettiğinizde değildir. Varsayımlarınıza, duruşmalarınıza ve belgelenmemiş davranışlarınıza dayanarak optimize ettiğiniz zamandır. Belgelenir ve daha verimli / mantıklı bir şekilde bir şey yapar ancak küçük olmasına rağmen, buna iyi optimizasyon diyorum . Diğerlerinin de belirttiği gibi, her ikisinin de eksileri var ve neredeyse hiç kazanamadığınız sürece artıları yok. Ancak, iyi okunabilirlik söz konusu olduğunda, ancak ikinciyi değil, yine de okunabilirliği tamamen ortadan kaldırmazsa , ikincisini yapıyorum . Evet okunabilirlik / bakım kolaylığı son derece önemlidir ve çizgiyi çizdiğiniz yerle ilgilidir.

Burada, başkalarının iyi ve kötü optimizasyonların olanağı olarak ortaya koydukları noktaları tekrar edeceğim:

  1. Belirli bir probleme olan bağımlılığınız değişebilir ve uygulamanızın mantıksal bölümünü tamamlamadan önce optimizasyon için harcadığınız zaman zaman kaybıdır. Ben nispeten erken bir aşamada optimize demek. Bugün List<T>, uygulamanızın gönderildiği tarihte bunu değiştirmek zorunda kaldınız LinkedList<T>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 olabilir (çoğunlukla sql olanlar) ve diğer% 95’i optimize etmek müşterilerinize 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 neden olan kod anlamına gelir; bu da daha zor bir bakım yapılabilirlik ve daha fazla zaman harcanması anlamına gelir; bu da daha az para kazanmanız anlamına gelir.

  4. % 1 performans kazancıyla tüm dünya için biriktirdiğiniz karbon ayak izi, ekibinizin hata ayıklama ve bu kodu sürdürme konusunda yaymak zorunda kalacağı sera gazları tarafından kolayca azaltılabilir.

Özellikle kötü optimizasyonun olumsuz yönleri :

  1. Size genellikle beklediğiniz performansı vermedi. Optimizasyonların yanlış gittiği SO'da bu soruya bakın . Aslında yapabilirsiniz olumsuz etkileri vardır. Belgelenmemiş davranışlarda sorun budur.

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

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

Kötü -

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

  2. ++i yerine kullanılan i++

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

  4. kapalı değişkenleri önlemek

    string p;
    foreach (var item in collection)
        p = ...;
    
  5. charstring birleştirme sırasında string yerine string kullanarak ,

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

İyi (.NET dünyasından. Kendi kendini 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)
    {
    
    }
    

Bana bunların gözle görülür bir performans avantajı sağlayıp sağlamadığını sorarsanız, hayır derdim. Fakat birisinin bunları kullanması gerektiğini ö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 bakıldığında iyi kodlama uygulaması. Ve 1 ve 3, katı terimlerle de biraz daha az okunabilir durumdadır, ancak okunabilirliği koyarlar mı? Hayır, fazla değil, kullanıyorum. Şimdi anahtar - okunabilirlik oranına uygun bir performansı korumak. Ve o zaman, çizgiyi çizdiğiniz yerle ilgili.


1

Yazmaya ve okumanın ve sürdürmenin ne kadar basit olduğu gibi, "bir şey değerinin" bağlamda olması gerektiği gibi, kullanıcının bir şeyi ne kadar hızlı hale getirdiği gibi daha duyarlı, etkileşimli ve beklemeleri için daha az zaman gerektirir.

Birkaç kuruşa bir kutu gazoz almak için para biriktirmek, özellikle de bu günlerde nadiren soda içtiğim göz önüne alındığında, bu paraları kurtarmak için bir mesafeye seyahat etmek zorunda kalmam durumunda, bana pek iyi gelmeyecek. Bir milyon kutu soda satın almak için kutu başına birkaç kuruş tasarruf etmek büyük bir anlaşma olabilir.

Bu arada, iki kişi hemen yanımda olduğunda ve biri birkaç penni için aynı şeyi teklif ettiğinde, diğeri ucuza geldiğinde, diğeri ise daha ucuz olanı seçti ve daha pahalı birini seçtim çünkü şapkaları aptalca bir dava gibi görünüyor. kötüye kullanma.

Sık sık "mikro optimizasyonlar" diyen insanları, benim için önemsiz olmadıklarında, bu tür optimizasyonları göz önünde bulundurmak için mutlaka üçü olması gerektiğinde, ölçümlerden, bağlamdan ve kullanıcı sonu tartışmalarından merakla mahrum görünüyorlar. Bana göre uygun bir mikro-optimizasyon bu günlerde bellek düzenleri ve erişim düzenleri gibi şeylerle ilgilidir ve odakta "mikro" gibi görünseler de, mikro etkide değildirler.

Çok uzun zaman önce, bir işlemi 24 saniyeden 25 milisaniyeye (yaklaşık 960 kat daha hızlı) düşürdüm, aynı çıktılarla (otomatik testlerle güvence altına alındı), hacimsel ısı difüzyonu için, algoritmik karmaşıklıkta değişiklik yapmadan "mikro-optimizasyonlar" (bunların en büyüğü yaklaşık 2 saniyeye inen bellek düzenindeki bir değişiklikten geldi, geri kalanı SIMD ve VTune'daki önbellek kayıplarının analizi ve bellek düzeninin yeniden düzenlenmesi gibi şeylerdi).

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

Uygulamam bunu bir dakikadan daha azına indirmek için uğraşırken milisaniyede yapabildi: görüntü tanımını buraya girin

"Mikro-optimizasyon" yaptıktan sonra 24 sn'den 25 ms'ye düşürdüm, bu iş akışında bir oyun değiştiriciydi. Artık sanatçılar, ekipmanlarını her küçük değişiklikten sonra 24 saniye beklemeden, 30 FPS'de gerçek zamanlı olarak kulelerini değiştirebiliyor. Ve bu aslında yazılımımın tasarımını değiştirdi, çünkü artık ilerleme çubuğuna ve bu tür şeylere ihtiyacım yoktu, hepsi etkileşimli hale geldi. Bu, tüm iyileştirmelerin algoritmik karmaşıklıkta herhangi bir iyileştirme olmadan ortaya çıktığı anlamında bir "mikro-optimizasyon" olabilir, ancak daha önce ağrılı ve etkileşimli olmayan bir işlem yapan aslında "mega-optimizasyon" idi. Gerçek zamanlı olarak, etkileşimli bir şekilde kullanıcıların çalışma şeklini tamamen değiştirdi.

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

Robert'ın buradaki yorumunu gerçekten beğendim ve belki de istediğim şeyi yapamadım:

Hadi, hadi. Hiç kimse bu tür bir değişimin “buna değmeyeceğini” iddia edemez. Maddi bir fayda gösterebildiniz; birçok mikro optimizasyon denilen olamaz.

Bu, çoğu zaman gerçek zamanlı gereklilikleri olan çok kritik bir alanda çalışmasına rağmen, yolumdan çıkmayı gerektiren herhangi bir mikro-optimizasyonu düşündüğüm tek zaman.

Ve sadece ölçümleri değil, kullanıcı tarafını da vurgularım. Şu anki alana (ve daha önce gamedev'e) ilk önce bir kullanıcı / hayranım, geliştirici olarak geldiğimde tuhafım. Bu yüzden, teknik bulmaca çözme gibi programcıları heyecanlandıran olağan şeyler beni hiç bu kadar heyecanlandırmamıştı; Onlara bir yük buldum, ancak diğer kullanıcılarla paylaştığım kullanıcı sonu rüyası boyunca onların arasından geçecekti. Ancak bu, eğer bir şeyi optimize edersem, kullanıcılar için gerçek fayda sağlayan gerçek bir etkiye sahip olacağından emin olmamı sağladı. Bu amaçsızca mikro optimizasyona karşı korumam.

Bu aslında benim açımdan profilci kadar önemli, çünkü bir küpün mikro-optimize alt bölümlerini milyarlarca fasete dönüştüren, sadece karakter ve araçlar gibi gerçek dünya üretim modellerinde boğulmak gibi şeyler yapan meslektaşlarım vardı. Elde ettikleri sonuçlar “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 uyuşmayan davaları profillendiriyor ve ölçüyorlardı. Bu nedenle, ilk önce kullanıcılar için neyin önemli olduğunu, yazılımı düşünmeyi ve kullanmayı düşünerek veya onlarla birlikte çalışarak (ideal olarak her ikisi için de, ama en azından bunlarla işbirliği yaparak) anlamak çok önemlidir.


2
Hadi, hadi. Hiç kimse bu tür bir değişimin “buna değmeyeceğini” iddia edemez. Maddi bir fayda gösterebildiniz; birçok mikro optimizasyon denilen olamaz.
Robert Harvey

1
@RobertHarvey Ben yapmak umuyordum noktanın nazikti, bazı insanlar vb ölçümler, aslında zorunlu olarak mikroskobik değil, ama o bağlamda o kadar bağımlı olduğunu "mikro-optimizasyonu" dediğimiz beri issetvs strlenodakta daha minik görünüyor bağlam ve ölçümler yoktur. :-D
Dragon Energy

1
@RobertHarvey Belki de dolaylı olarak da olsa, "mikro optimizasyonlar" için olumsuz bir bağlam varsa, bu ölçümlerden, bağlamlardan ve kullanıcı sonu gereksinimlerinden yoksun olma eğiliminde olan bir tür olduğunu söylemeyi umuyordum. Hiç kimseyi kullanmadıysanız, serin olan bir şeyden cehennemi optimize eden bir meslektaşım olduğu için son dava hakkında da devam edebilirdim. Uygun optimizasyonun bazı kullanıcı sonu anlayışları gerektirdiğini bile düşünüyorum, aksi takdirde kullanıcıların umursamadığı şeyleri profillendirip ayarlayabiliriz.
Dragon Enerji

1
Bazı optimizasyonlar ihtiyaç duymaya, bazıları merakla (entelektüel arayış ve maceracılık) yönlendirilir. İkimize de ihtiyacımız var. Dragon Energy'nin öyküsünde, büyük olasılıkla "acil bir ihtiyaç" değildi, çünkü sanatçılar her düzenlemeden 24 saniye sonrasına kadar herhangi bir oluşturma sonucunu görmeme konusunda yüksek sesle şikayet etmediler. Aslında, kullanıcılar bir programcı hız rekorunu kırma çabasına yatırım yapana kadar ne kadar hızlı olacağını bilemeyebilir. Kendimizi yönlendiren talebe sınırlamak iş anlamında bir anlam ifade etse de, bunu yapmak inanılmaz şaşırtıcı optimizasyon fırsatlarını veya oyun değiştiricileri özleyecektir.
rwong

1
İş dünyasından bahsetmişken, para kazanma konusu da var. Her hareket (örneğin, performans optimizasyonu üzerinde çalışan bir programcı) paraya mal olur ve iş mantıklı olması için maliyetin geri kazanılması gerekir. Bu nedenle, programcı bir işletme yöneticisinden onay alması gerekiyorsa, oyun değiştiren hız iyileştirmesinin "satılabileceğini" veya ne kadar para kazanılacağını "sorması gerekir.
rwong

0

Bu şekilde koyacağım - mikro-optimizasyon bir darboğaz olmayan bir şeyi optimize etme sürecidir. Örneğin, programınız A ve B iki işlevini çağırıyorsa ve A tamamlamak için 100 milisaniye alırsa ve B 2 mikrosaniye alırsa ve B işlevini en iyi duruma getirmeye devam edersiniz. Bu sadece önemli değil, bu kesinlikle yanlıştır. Ancak optimizasyon işlevi B, optimizasyon olarak adlandırılır ve mikro optimizasyon değil. Optimizasyonun önemi bağlıdır. Yapacak başka bir şeyin olmadığını ve programın hatasız olduğunu söyle, sonra evet, önemli. Ama genel olarak önceliklerin var. Diyelim ki, C fonksiyonunu ekleyip / yazmalısınız. Diyelim ki, C fonksiyonunun C yazma fonksiyonunun programınızı bu fonksiyonellik olmadan daha hızlı hale getirmekten daha fazla para kazandıracağını düşünüyorsanız, optimizasyon için devam edin. Aksi takdirde işlevsellik takip edin. Ayrıca, Performansa odaklanmış deneyimli programcılar optimizasyon için çok fazla zaman harcamazlar, sadece hızlı programlar yazarlar. En azından, hangi araçları kullanacaklarını ve yıllarını anlamsız (mikro okuma) optimizasyonları yaparak geçirmeyeceklerini biliyorlar.


Bu yazı okumak oldukça zordur (metin duvarı). Sakıncası var düzenleyebilir daha iyi bir şekle ing?
tatarcık
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.