Gördüğünüz en saçma kötümserlik nedir? [kapalı]

Erken optimizasyonun tüm kötülüklerin kökü olduğunu hepimiz biliyoruz çünkü okunamayan / sürdürülemez koda yol açıyor. Daha da kötüsü, bir kişi "optimizasyon" u daha hızlı olacağını düşündüğü için uyguladığında , ancak sonuçta daha yavaş, hatalı, sürdürülemez vb. Hale geldiğinde, karamsarlıktır . Bunun gördüğünüz en saçma örnek nedir? ?

Eski bir projede, muazzam Z-8000 deneyimine sahip bazı (aksi halde mükemmel) gömülü sistem programcılarını miras aldık.

Yeni ortamımız 32-bit Sparc Solaris idi.

Adamlardan biri girdi ve kodumuzu hızlandırmak için tüm girişleri kısaya çevirdi, çünkü RAM'den 16 bit kapmak 32 bit kapmaktan daha hızlıydı.

32 bitlik bir sistemde 32 bitlik değerlerin yakalanmasının 16 bitlik değerlerin yakalanmasından daha hızlı olduğunu göstermek için bir demo programı yazmam ve 16 bitlik bir değer elde etmek için CPU'nun 32 bit genişliğinde olması gerektiğini açıklamam gerekiyordu. bellek erişimi ve ardından 16 bitlik değer için gerekli olmayan bitleri maskeleyin veya kaydırın.

"Zamanından önce optimizasyon tüm kötülüklerin köküdür" ifadesinin çok fazla kullanıldığını düşünüyorum. Birçok proje için, bir projenin geç dönemlerine kadar performansı hesaba katmamak bir bahane haline geldi.

Bu söz genellikle insanların çalışmaktan kaçınması için bir koltuk değneğidir. İnsanların gerçekten "Tanrım, bunu önceden düşünmemiştik ve şimdi bununla başa çıkmak için zamanımız yok" demesi gerektiğinde bu cümlenin kullanıldığını görüyorum.

"Karamsarlık" nedeniyle ortaya çıkan sorunların örneklerinden çok daha "saçma" aptal performans sorunları örnekleri gördüm

• Program başlatılırken aynı kayıt defteri anahtarını binlerce (veya 10 bin) kez okuma.
• Aynı DLL'yi yüzlerce veya binlerce kez yükleme
• Dosyalara giden tam yolları gereksiz yere tutarak mega bayt bellek israfı
• Veri yapılarını, ihtiyaç duyduklarından çok daha fazla bellek kaplayacak şekilde düzenlememek
• Dosya adlarını veya yollarını MAX_PATH olarak saklayan tüm dizeleri boyutlandırma
• Olaylar, geri aramalar veya diğer bildirim mekanizmaları olan şeyler için karşılıksız yoklama

Daha iyi bir ifade olduğunu düşündüğüm şey şudur: "Ölçmeden ve anlamadan optimizasyon hiç optimizasyon değildir - sadece rastgele değişimdir".

İyi Performans çalışması zaman alıcıdır - çoğu zaman daha çok özellik veya bileşenin kendisinin geliştirilmesi.

Veritabanları kötümserlik oyun alanlarıdır.

Favoriler şunları içerir:

• "Çok büyük" olduğu için bir tabloyu katlara (tarih aralığına, alfabetik aralığa vb. Göre) bölün.
• Kullanımdan kaldırılan kayıtlar için bir arşiv tablosu oluşturun, ancak bunu üretim tablosuyla birleştirmeye devam edin.
• Tüm veritabanlarını (bölüm / müşteri / ürün / vb.)
• Bir dizine sütun eklemeye direnin çünkü çok büyük yapar.
• Ham verilerden yeniden hesaplama çok yavaş olduğu için çok sayıda özet tablosu oluşturun.
• Yer kazanmak için alt alanlara sahip sütunlar oluşturun.
• Bir dizi olarak alanlara denormalize edin.

Bu aklımın ucunda.

Bence mutlak bir kural yok: bazı şeyler önceden optimize edilmiş, bazıları ise değil.

Örneğin uydulardan veri paketleri aldığımız bir şirkette çalıştım. Her paketin maliyeti çok büyüktü, bu nedenle tüm veriler yüksek düzeyde optimize edildi (yani paketlendi). Örneğin, enlem / boylam mutlak değerler (yüzen) olarak değil, "mevcut" bir bölgenin "kuzey-batı" köşesine göre ofsetler olarak gönderildi. Kullanılmadan önce tüm verileri paketinden çıkarmak zorunda kaldık. Ama bence bu bir kötümserlik değil, iletişim maliyetlerini düşürmek için akıllı bir optimizasyon.

Öte yandan, yazılım mimarlarımız, paketlenmemiş verilerin çok okunabilir bir XML belgesine biçimlendirilmesi ve bu şekilde veritabanımızda saklanması gerektiğine karar verdiler (her alanın karşılık gelen bir sütunda depolanması yerine). Fikirleri, "XML geleceğidir", "disk alanı ucuzdur" ve "işlemci ucuzdur", dolayısıyla hiçbir şeyi optimize etmeye gerek yoktu. Sonuç olarak, 16 baytlık paketlerimiz tek bir sütunda saklanan 2kB dokümanlara dönüştürüldü ve basit sorgular için bile megabaytlık XML belgelerini belleğe yüklememiz gerekti! Saniyede 50'den fazla paket aldık, böylece performansın ne kadar korkunç olduğunu tahmin edebilirsiniz (BTW, şirket iflas etti).

Yani yine, mutlak bir kural yok. Evet, bazen optimizasyon çok erken bir hatadır. Ancak bazen "cpu / disk alanı / bellek ucuzdur" sloganı tüm kötülüklerin gerçek köküdür.

Aman Tanrım, hepsini gördüm galiba. Çoğu zaman, bu performans sorunlarının nedenini gideremeyecek kadar tembel olan veya hatta gerçekten bir performans sorunu olup olmadığını araştıran birinin performans sorunlarını çözme çabasıdır. Bu vakaların çoğunda, sadece belirli bir teknolojiyi denemek isteyen ve umutsuzca parlak yeni çekicine uyan bir çivi arayan kişinin durumu olup olmadığını merak ediyorum.

İşte yeni bir örnek:

Veri mimarı, oldukça büyük ve karmaşık bir uygulamada bir anahtar tabloyu dikey olarak bölümlere ayırmak için ayrıntılı bir öneriyle geliyor. Değişikliğe uyum sağlamak için ne tür bir geliştirme çabası gerektiğini bilmek istiyor. Sohbet şöyle gelişti:

Ben: Bunu neden düşünüyorsunuz? Çözmeye çalıştığınız problem nedir?

O: Tablo X çok geniş, performans nedenleriyle bölümlere ayırıyoruz.

Ben: Çok geniş olduğunu düşündüren nedir?

O: Danışman, bunun tek bir masada olması için çok fazla sütun olduğunu söyledi.

Ben: Ve bu performansı etkiliyor mu?

Him: Evet, kullanıcılar uygulamanın XYZ modülünde aralıklı yavaşlamalar bildirdiler.

Ben: Sorunun kaynağının tablonun genişliği olduğunu nereden biliyorsunuz?

Him: Bu, XYZ modülünün kullandığı anahtar tablodur ve 200 sütun gibidir. Sorun bu olmalı.

Ben (Açıklama): Ancak özellikle XYZ modülü bu tablodaki sütunların çoğunu kullanır ve kullandığı sütunlar tahmin edilemez çünkü kullanıcı uygulamayı o tablodan görüntülemek istediği verileri gösterecek şekilde yapılandırır. Muhtemelen zamanımızın% 95'inde tüm masaları bir araya getirmekle sonuçlanırdık, bu da performansımızı düşürür .

O: Danışman çok geniş olduğunu ve onu değiştirmemiz gerektiğini söyledi.

Ben: Bu danışman kim? Bir danışman tuttuğumuzu bilmiyordum, geliştirme ekibiyle de hiç konuşmadılar.

O: Şey, henüz onları işe almadık. Bu, sundukları bir teklifin parçası, ancak bu veritabanını yeniden yapılandırmamız gerektiğinde ısrar ettiler.

Ben: Uh huh. Dolayısıyla, veritabanı yeniden tasarım hizmetleri satan danışman, veritabanının yeniden tasarlanmasına ihtiyacımız olduğunu düşünüyor ...

Sohbet böyle devam etti. Daha sonra söz konusu tabloya bir kez daha baktım ve egzotik bölümleme stratejilerine gerek kalmadan bazı basit normalleştirme ile daraltılabileceğini belirledim. Bu, elbette performans sorunlarını araştırdığımda (daha önce bildirilmemişti) ve bunları iki faktöre indirdiğimde tartışmalı bir nokta haline geldi:

1. Birkaç anahtar sütunda eksik dizinler.
2. Üretim veritabanını doğrudan MSAccess ile sorgulayarak anahtar tablolarını ("çok geniş" olanlar dahil) periyodik olarak kilitleyen birkaç hileli veri analisti.

Tabii ki mimar hala "çok geniş" meta-problemin üzerinde asılı duran tablonun dikey olarak bölünmesi için bastırıyor. Hatta uygulamaya bakmadan veya herhangi bir performans analizi çalıştırmadan veritabanında büyük tasarım değişikliklerine ihtiyacımız olduğunu belirleyebilen başka bir veritabanı danışmanından bir teklif alarak durumunu güçlendirdi.

CHX-LT'yi tamamen kuluçkaya yatırmak için alphadrive-7 kullanan insanlar gördüm. Bu alışılmadık bir uygulamadır. Daha yaygın uygulama, tamponlamanın azaltılması (daha yüksek net aşırı yük direncine bağlı olarak) için ZT transformatörünü başlatmak ve java tarzı baytgrafikasyonlar oluşturmaktır.

Tamamen karamsar!

Dünyayı sarsan bir şey değil, kabul ediyorum, ama Java'da bir döngü dışında StringBuffer kullanan insanları yakaladım. Dönmek gibi basit bir şeydi

String msg = "Count = " + count + " of " + total + ".";

içine

StringBuffer sb = new StringBuffer("Count = ");
sb.append(count);
sb.append(" of ");
sb.append(total);
sb.append(".");
String msg = sb.toString();

Tekniği bir döngüde kullanmak oldukça yaygın bir uygulamadır çünkü ölçülebilir derecede daha hızlıydı. Mesele şu ki, StringBuffer senkronize edildi, bu yüzden sadece birkaç String'i birleştiriyorsanız aslında fazladan ek yük var. (Farkın bu ölçekte kesinlikle önemsiz olduğundan bahsetmiyorum bile.) Bu uygulama hakkında diğer iki nokta:

1. StringBuilder eşitlenmemiş olduğundan, kodunuzun birden çok iş parçacığından çağrılamadığı durumlarda StringBuffer yerine tercih edilmelidir.
2. Modern Java derleyicileri, okunabilir String birleştirmeyi uygun olduğunda sizin için optimize edilmiş bayt koduna dönüştürecektir.

Bir keresinde 'Kök' tablosu kullanan bir MSSQL veritabanı görmüştüm. Kök tablosunun dört sütunu vardı: GUID (benzersiz tanımlayıcı), ID (int), LastModDate (datetime) ve CreateDate (datetime). Veritabanındaki tüm tablolar Kök tabloya Yabancı Anahtarlı idi. Veritabanındaki herhangi bir tabloda yeni bir satır oluşturulduğunda, ilgilendiğiniz gerçek tabloya ulaşmadan önce Kök tablosuna bir giriş eklemek için birkaç saklı yordam kullanmanız gerekir (bunun için işi yapan veritabanı yerine) birkaç tetikleyici basit tetikleyici ile).

Bu, işe yaramaz bir kulak misafiri ve baş ağrısı karmaşası yarattı, üzerine yazılan herhangi bir şeyin dişlileri kullanmasını gerektirdi (ve LINQ'i şirkete tanıtma umudumu ortadan kaldırdı. Mümkündü ama baş ağrısına değmezdi) ve üstesinden gelmek de değildi '' Yapması gerekeni bile başarmak.

Bu yolu seçen geliştirici, tabloların kendisinde Kılavuzları kullanmadığımız için bunun tonlarca alan tasarrufu sağladığını varsayarak savundu (ancak ... yaptığımız her satır için Kök tablosunda bir GUID oluşturulmadı mı?) , bir şekilde iyileştirilmiş performans ve veritabanındaki değişikliklerin denetlenmesini "kolaylaştırdı".

Oh, ve veritabanı diyagramı cehennemden gelen mutant bir örümceğe benziyordu.

Peki ya POBI - açıkça kasıtlı kötümseme?

90'lı yıllardaki meslektaşım, CEO'nun her ERP yazılımı (özel bir yazılım) sürümünün ilk gününü yeni işlevlerdeki performans sorunlarını bulmakla geçirdiği için CEO tarafından kıçına tekme atılmasından yorulmuştu. Yeni işlevler gigabaytları sıkıştırıp imkansızı mümkün kılmış olsa bile, her zaman üzerine sızlanacak bazı ayrıntılar ve hatta görünüşte önemli bir sorun buldu. Programlama hakkında çok şey bildiğine inanıyordu ve programcı kıçlarını tekmeleyerek tekmeledi.

Eleştirinin yetersiz doğası nedeniyle (o bir BT adamıydı, bir CEO'ydu), meslektaşım hiçbir zaman doğru anlayamadı. Performans probleminiz yoksa ortadan kaldıramazsınız ...

Bir sürüm için, yeni koda çok sayıda Gecikme (200) işlev çağrısı (Delphi idi) koydu. Yayına alındıktan sonra sadece 20 dakika sürdü ve gecikmiş hakaretlerini şahsen almak için CEO'nun ofisinde görünmesi emredildi.

Şimdiye kadarki tek alışılmadık şey, meslektaşlarım döndüğünde, gülümsediğinde, şakalaşarak, bir ya da iki BigMac için dışarı çıktığında sessiz kalmasıydı, bu sırada normalde masaları tekmeliyor, CEO ve şirket hakkında alevleniyor ve günün geri kalanını ölüme terk ederek geçiriyordu. .

Doğal olarak, meslektaşım şimdi bir veya iki gün masasında dinlendi, Quake'de nişan alma becerilerini geliştirdi - sonra ikinci veya üçüncü günde Gecikme çağrılarını sildi, yeniden inşa etti ve duyurduğu bir "acil durum yaması" yayınladı. performans açıklarını düzeltmek için 2 gün 1 gece geçirdiğini söyledi.

Bu, kötü CEO'nun "harika iş" dediği ilk (ve tek) zamandı! ona. Önemli olan bu, değil mi?

Bu gerçek POBI idi.

Ama aynı zamanda bir tür sosyal süreç optimizasyonu, bu yüzden% 100 sorun değil.

Bence.

"Veritabanı Bağımsızlığı". Bu, saklanan hiçbir işlem, tetikleyici vb. Anlamına gelmiyordu - herhangi bir yabancı anahtar bile.

var stringBuilder = new StringBuilder();
stringBuilder.Append(myObj.a + myObj.b + myObj.c + myObj.d);
string cat = stringBuilder.ToString();

Şimdiye kadar gördüğüm en iyi StringBuilder kullanımı.

Basit bir dize.split yeterli olduğunda bir dizeyi bölmek için bir normal ifade kullanma

Biliyorum bu konuya çok geç, ama bunu yakın zamanda gördüm:

bool isFinished = GetIsFinished();

switch (isFinished)
{
    case true:
        DoFinish();
        break;

    case false:
        DoNextStep();
        break;

    default:
        DoNextStep();
}

Biliyor musun, bir mantıksal değerin bazı ekstra değerleri olması durumunda ...

Aklıma gelen en kötü örnek, şirketimdeki tüm çalışanlar hakkında bilgi içeren dahili bir veritabanıdır. İK'dan her gece bir güncelleme alır ve üstte bir ASP.NET web hizmeti vardır. Diğer birçok uygulama, arama / açılır alanlar gibi şeyleri doldurmak için web hizmetini kullanır.

Kötümserlik, geliştiricinin, web servisine yapılan tekrarlanan çağrıların, tekrarlanan SQL sorguları yapmak için çok yavaş olacağını düşünmesidir. Peki o ne yaptı? Uygulama başlatma olayı tüm veritabanını okur ve hepsini bellekteki nesnelere dönüştürür, uygulama havuzu geri dönüştürülene kadar süresiz olarak depolanır. Bu kod o kadar yavaştı ki 2000'den az çalışanda yüklenmesi 15 dakika sürerdi. Uygulama havuzunu gün içinde yanlışlıkla geri dönüştürdüyseniz, her web hizmeti isteği birden çok eşzamanlı yeniden yüklemeyi başlatacağından 30 dakika veya daha uzun sürebilir. Bu nedenle, yeni işe alınan kişiler, hesaplarının oluşturulduğu ilk gün veritabanında görünmez ve bu nedenle, çoğu dahili uygulamaya ilk birkaç gününde parmaklarını çevirerek erişemezler.

İkinci kötümserlik seviyesi, geliştirme yöneticisinin bağımlı uygulamaları bozma korkusuyla ona dokunmak istememesidir, ancak yine de böylesine basit bir bileşenin zayıf tasarımı nedeniyle şirket genelinde kritik uygulamalarda ara sıra kesintiler yaşamaya devam ediyoruz.

Görünüşe göre kimse sınıflandırmadan bahsetmemiş, ben de söyleyeceğim.

Birkaç kez, birinin el yapımı bir balonlar sıralaması yaptığını keşfettim, çünkü durum zaten var olan "çok süslü" hızlı sıralama algoritmasına bir çağrı "gerektirmiyordu". Geliştirici, kendi el yapımı baloncukları test etmek için kullandıkları on veri satırı üzerinde yeterince iyi çalıştığında memnun oldu. Müşteri birkaç bin satır ekledikten sonra pek iyi gitmedi.

Bir keresinde bunun gibi kodlarla dolu bir uygulama üzerinde çalıştım:

 1 tuple *FindTuple( DataSet *set, int target ) {
 2     tuple *found = null;
 3     tuple *curr = GetFirstTupleOfSet(set);
 4     while (curr) {
 5         if (curr->id == target)
 6             found = curr;
 7         curr = GetNextTuple(curr);
 8     }
 9     return found;
10 }

Basitçe kaldırarak found, nullsonunda geri dönerek ve altıncı satırı şu şekilde değiştirerek:

            return curr;

Uygulama performansını iki katına çıkardı.

Bir keresinde Constants sınıfında bu mücevherleri içeren kodu değiştirmeye çalışmak zorunda kaldım

public static String COMMA_DELIMINATOR=",";
public static String COMMA_SPACE_DELIMINATOR=", ";
public static String COLIN_DELIMINATOR=":";

Bunların her biri, uygulamanın geri kalanında farklı amaçlar için birden çok kez kullanıldı. COMMA_DELIMINATOR, kodu 8 farklı pakette 200'den fazla kullanımla doldurdu.

Şirket içi yazılımda tekrar tekrar karşılaştığım tüm zamanların en büyüğü:

"Daha sonra başka bir satıcıya geçmek isteyebileceğimiz için" "taşınabilirlik" nedenleriyle DBMS'nin özelliklerini kullanmamak.

Dudaklarımı oku. Herhangi bir kurum içi çalışma için: OLMAYACAKTIR!

C derleyicimizin optimize edicisini alt etmeye ve sadece onun okuyabileceği rutin kodu yeniden yazmaya çalışan bir iş arkadaşım vardı. En sevdiği püf noktalarından biri, okunabilir bir yöntemi değiştirmekti (bazı kodlar oluşturmak):

int some_method(int input1, int input2) {
    int x;
    if (input1 == -1) {
        return 0;
    }
    if (input1 == input2) {
        return input1;
    }
    ... a long expression here ...
    return x;
}

bunun içine:

int some_method() {
    return (input == -1) ? 0 : (input1 == input2) ? input 1 :
           ... a long expression ...
           ... a long expression ...
           ... a long expression ...
}

Yani, bir kez okunabilir bir yöntemin ilk satırı " return" olur ve diğer tüm mantık, derinlemesine iç içe geçmiş üçlü ifadelerle değiştirilir. Bunun nasıl sürdürülemez olduğunu tartışmaya çalıştığınızda, yönteminin montaj çıktısının üç veya dört montaj talimatının daha kısa olduğu gerçeğine işaret ederdi. Daha hızlı değildi ama her zaman küçücüktü biraz daha kısa. Bu, bellek kullanımının ara sıra önemli olduğu gömülü bir sistemdi, ancak kodu okunabilir bırakacak şekilde yapılabilecek daha kolay optimizasyonlar vardı.

Sonra, bundan sonra, bir nedenden ötürü, ptr->structElementbunun çok okunamaz olduğuna karar verdi , bu yüzden tüm bunları (*ptr).structElement, daha okunabilir ve daha hızlı olduğu teorisine dönüştürmeye başladı .

Okunabilir kodu, en fazla% 1'lik bir iyileştirme ve bazen daha yavaş kod için okunamaz koda dönüştürmek.

Tam teşekküllü bir geliştirici olarak ilk işlerimden birinde, ölçeklendirme sorunları olan bir program için bir projeyi devraldım. Küçük veri kümelerinde oldukça iyi çalışır, ancak büyük miktarlarda veri verildiğinde tamamen çökebilir.

Araştırdığımda, orijinal programcının analizi paralel hale getirerek her ek veri kaynağı için yeni bir iş parçacığı başlatarak işleri hızlandırmaya çalıştığını gördüm. Ancak, tüm iş parçacıklarının kilitlendiği paylaşılan bir kaynak gerektirdiği için bir hata yapmıştı. Elbette eşzamanlılığın tüm faydaları ortadan kalktı. Dahası, çoğu sistemi yalnızca biri hariç tümü kilitlemek için 100'den fazla iş parçacığı başlatmak için çöktü. Benim etli dev makinem, yaklaşık 6 saat içinde 150 kaynaklı bir veri kümesinden geçmesi açısından bir istisnaydı.

Bu yüzden düzeltmek için, çok iş parçacıklı bileşenleri çıkardım ve G / Ç'yi temizledim. Başka hiçbir değişiklik yapılmadan, 150 kaynaklı veri setindeki yürütme süresi makinemde 10 dakikanın altına ve ortalama şirket makinesinde sonsuzdan yarım saatin altına düştü.

Sanırım bu mücevheri sunabilirim:

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1, root = 0;
    #define ISQRT_INNER(shift) \
    { \
        if (value >= (tmp = ((root << 1) + (1 << (shift))) << (shift))) \
        { \
            root += 1 << shift; \
            value -= tmp; \
        } \
    }

    // Find out how many bytes our value uses
    // so we don't do any uneeded work.
    if (value & 0xffff0000)
    {
        if ((value & 0xff000000) == 0)
            tmp = 3;
        else
            tmp = 4;
    }
    else if (value & 0x0000ff00)
        tmp = 2;

    switch (tmp)
    {
        case 4:
            ISQRT_INNER(15);
            ISQRT_INNER(14);
            ISQRT_INNER(13);
            ISQRT_INNER(12);
        case 3:
            ISQRT_INNER(11);
            ISQRT_INNER(10);
            ISQRT_INNER( 9);
            ISQRT_INNER( 8);
        case 2:
            ISQRT_INNER( 7);
            ISQRT_INNER( 6);
            ISQRT_INNER( 5);
            ISQRT_INNER( 4);
        case 1:
            ISQRT_INNER( 3);
            ISQRT_INNER( 2);
            ISQRT_INNER( 1);
            ISQRT_INNER( 0);
    }
#undef ISQRT_INNER
    return root;
}

Karekök çok hassas bir yerde hesaplandığından, onu daha hızlı hale getirmenin bir yolunu bulma görevini aldım. Bu küçük yeniden düzenleme, yürütme süresini üçte bir oranında azalttı (kullanılan donanım ve derleyici kombinasyonu için, YMMV):

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1, root = 0;
    #define ISQRT_INNER(shift) \
    { \
        if (value >= (tmp = ((root << 1) + (1 << (shift))) << (shift))) \
        { \
            root += 1 << shift; \
            value -= tmp; \
        } \
    }

    ISQRT_INNER (15);
    ISQRT_INNER (14);
    ISQRT_INNER (13);
    ISQRT_INNER (12);
    ISQRT_INNER (11);
    ISQRT_INNER (10);
    ISQRT_INNER ( 9);
    ISQRT_INNER ( 8);
    ISQRT_INNER ( 7);
    ISQRT_INNER ( 6);
    ISQRT_INNER ( 5);
    ISQRT_INNER ( 4);
    ISQRT_INNER ( 3);
    ISQRT_INNER ( 2);
    ISQRT_INNER ( 1);
    ISQRT_INNER ( 0);

#undef ISQRT_INNER
    return root;
}

Elbette bunu yapmanın hem daha hızlı hem de daha iyi yolları var, ama bence bu oldukça düzgün bir karamsarlık örneği.

Düzenleme: Bir düşünün, açılmış döngü aslında aynı zamanda düzgün bir pessimizasyondu. Sürüm kontrolüne rağmen, yukarıdakilerden daha iyi performans gösteren yeniden düzenlemenin ikinci aşamasını da sunabilirim:

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1 << 30, root = 0;

    while (tmp != 0)
    {
        if (value >= root + tmp) {
            value -= root + tmp;
            root += tmp << 1;
        }
        root >>= 1;
        tmp >>= 2;
    }

    return root;
}

Bu, biraz farklı bir uygulama olsa da, tamamen aynı algoritmadır, bu yüzden uygun olduğunu düşünüyorum.

Bu, peşinde olduğunuzdan daha yüksek bir düzeyde olabilir, ancak düzeltmek (izin veriliyorsa) aynı zamanda daha yüksek düzeyde ağrı içerir:

Yerleşik, test edilmiş, olgun kitaplıklardan birini kullanmak yerine (size gösterildikten sonra bile) bir Nesne İlişkisi Yöneticisi / Veri Erişim Katmanı'nı el ile yuvarlamakta ısrar etmek.

Tüm yabancı anahtar kısıtlamaları bir veritabanından kaldırıldı, çünkü aksi takdirde çok fazla hata olurdu.

Bu soruya tam olarak uymuyor, ancak yine de uyarıcı bir masaldan bahsedeceğim. Yavaş çalışan, dağıtılmış bir uygulama üzerinde çalışıyordum ve öncelikle sorunu çözmeyi amaçlayan bir toplantıya katılmak için DC'ye uçtum. Proje lideri, gecikmeyi çözmeyi amaçlayan bir yeniden mimariyi özetlemeye başladı. Hafta sonu boyunca darboğazı tek bir yöntemle izole eden bazı ölçümler yaptığıma gönüllü oldum. Yerel bir aramada eksik bir kayıt olduğu ortaya çıktı ve bu da uygulamanın her işlemde uzak bir sunucuya gitmesine neden oldu. Kaydı yerel mağazaya geri ekleyerek gecikme ortadan kaldırıldı - sorun çözüldü. Yeniden mimarinin sorunu çözmeyeceğini unutmayın.

HER javascript işleminden önce üzerinde çalıştığınız nesnenin var olup olmadığını kontrol etme.

if (myObj) { //or its evil cousin, if (myObj != null) {
    label.text = myObj.value; 
    // we know label exists because it has already been 
    // checked in a big if block somewhere at the top
}

Bu tür bir kodla ilgili sorunum, kimsenin umurunda değil, yoksa yoksa? Hiçbir şey yapmamak mı? Geri bildirimi kullanıcıya vermiyor musunuz?

Object expectedHataların can sıkıcı olduğuna katılıyorum , ancak bunun için en iyi çözüm bu değil.

YAGNI aşırılığına ne dersiniz? Erken bir kötümseme şeklidir. Görünüşe göre YAGNI'yi her uyguladığınızda, sonunda ona ihtiyaç duyuyorsunuz, bu da onu eklemek için başlangıçta eklemiş olmanıza kıyasla 10 kat daha fazla çaba sarf ediyor. Başarılı bir program yaratırsanız, o zaman büyük olasılıkla buna İHTİYACINIZ OLACAKTIR. Hayatı hızla biten programlar yaratmaya alışkınsanız, YAGNI'yi uygulamaya devam edin çünkü o zaman YAGNI olduğunu düşünüyorum.

Tam olarak erken optimizasyon değil - ama kesinlikle yanlış yönlendirilmiş - bu, Windows 7'yi tartışan bir makaleden BBC web sitesinde okundu.

Bay Curran, Microsoft Windows ekibinin iyileştirmeler yapmak için işletim sisteminin her yönünü incelediğini söyledi. "WAV dosyası kapatma müziğini biraz kırparak kapanma süresini 400 milisaniye azaltmayı başardık.

Şimdi, Windows 7'yi henüz denemedim, bu yüzden yanılıyor olabilirim, ancak orada, kapatmanın ne kadar sürdüğünden daha önemli olan başka sorunlar olduğuna bahse girmeye hazırım. Sonuçta, 'Windows'u Kapat' mesajını gördüğümde, monitör kapanıyor ve uzaklaşıyorum - bu 400 milisaniye bana nasıl fayda sağlıyor?

Bölümümden biri bir zamanlar bir string sınıfı yazdı. Gibi bir arayüzCStringWindows bağımlılığı olmayan .

Bir "optimizasyon" yaptılar oldu değil gerekenden daha fazla bellek ayrılamadı. Görünüşe göre sınıfların std::stringfazla bellek ayırmasının nedeninin bir dizi +=işlemin O (n) zamanında çalışabileceğinin farkında değiller .

Bunun yerine, her bir +=çağrı bir yeniden tahsisi zorladı ve bu tekrar tekrar bir O (n²) Schlemiel the Painter algoritmasına ekler .

Java ERP'miz için müşterilerin verilerini (perakende sektörü) toplaması ve analiz etmesi gereken yeni bir modül oluşturmak üzere eski bir iş arkadaşım ( aslında bir soab ) görevlendirildi. HER Takvim / Tarih-Saat alanını bileşenlerine (saniye, dakika, saat, gün, ay, yıl, haftanın günü, bimester, üç aylık dönem (!)) Ayırmaya karar verdi çünkü "'her pazartesi' için başka nasıl sorgulama yapardım?"

Kimseye gücenme, ama buna sahip bir ödeve (java) not verdim

import java.lang.*;