Bir işlevin Big O yürütme süresini değiştirdiğinizde buna ne denir [kapalı]

Diyelim ki bir veritabanını O(n^2)zamanında ayıran bir fonksiyonum var . Yeniden işlemeye devam etmek istiyorum, böylece O(n log(n))zamanında çalışır ve bunu yaparken, dönüş değerlerini ve girişlerini eşdeğer tutarken, işlemin temel yolunu değiştireceğim.

Bu yeniden düzenleme faaliyetine ne denir?

Bir algoritmayı yürüttüğü büyük O hızını değiştirmeden daha hızlı çalıştırabildiğiniz için, "hızlandırma-ifying" pek doğru görünmüyor.

"Basitleştirmek" de doğru görünmüyor.

Bu etkinliğe ne diyorum?

Güncelleme

Bulabildiğim en iyi cevap asimpotik zaman karmaşıklığını azaltmak.

Genellikle "performans optimizasyonu" denir , ancak bu terim tipik olarak görünür davranışını değiştirmeyen kod değişikliklerine atıfta bulunduğundan, "yeniden düzenleme" olarak adlandırmazdım . Ve Big-O'daki bir değişiklik kesinlikle görünür bir değişiklik diyeceğim bir şey.

böylece operasyonun temel yolunu değiştireceğim

Bu durumda, optimizasyonunuz bu işlevin yeniden yazılmasıdır . Her optimizasyon, "Big-O" değiştirse bile, mutlaka bir yeniden yazma işlemi değildir, bazen böyle bir iyileştirmeyi sağlamak için sadece küçük değişiklikler gerekir, ancak o zaman bile, bunun için "yeniden düzenleme" terimini kullanmakta isteksizim çünkü değişimin doğası hakkında yanlış bir izlenim bırakma eğilimindedir.

DÜZENLEME: Fowler'ın yeniden düzenleme listesini kontrol ettim ve bu ~ 100 adlı yeniden düzenleme arasında en sonuncusu "Yedek Algoritma" olarak adlandırılıyor . Bu yüzden bunu kanonik referans olarak alırsak, tarif edilen formun optimizasyonuna özel bir yeniden düzenleme adı verilebilecek küçük bir gri alan vardır (ancak IMHO tipik bir alan değildir). Ayrıca unutmayın, Fowler'in tüm yeniden düzenlemelerle hedefi, mevcut kodun yeniden yazılmadan sürdürülebilmesi ve geliştirilebilirliğine odaklanarak ve her zaman performans optimizasyonuna açık olmayan tasarımı geliştirmekti.

Ben sık kullanılmakta, standart bir terim olduğunu sanmıyorum optimize olsa iyileştirilmesi veya hızlandırmak ayrıca kod değişiklikleri ve olmayan donanım değişiklikleri bahsediyoruz o açıklama yaparak doğru olacaktır.

Diğerlerinin söylediği gibi, "optimizasyon" bir algoritmanın performansını artırmak için kullanılan genel terimdir. Ancak, optimizasyon genellikle sabit faktörlerin iyileştirilmesi anlamına gelir. Eğer asimptotik (zaman) karmaşıklığını azalttığımı kısaca ama açıkça belirtmek istersem, "asimptotik performansı iyileştirdiğimi" söyleyebilirim. Bazen insanlar bunu "ölçeğin iyileştirilmesi" olarak tanımlayacaktır, ancak bu günümüzde özellikle belirsizdir.

Uyarı : Asimptotik zaman karmaşıklığının azaltılması, pratik bir bağlamda optimizasyon ile aynı olmak zorunda değildir . Çoğu zaman asimtotik olarak optimal olmayan algoritmalar kullanılır, çünkü girdi aralığında program aslında daha az optimal algoritmalara daha az maruz kalır, daha iyi performans gösterir.

Bağlama bağlı olacaktır.

"İkinci dereceden çalışma zamanı performans hatasını düzeltmek" genellikle gördüğüm şeydir. Ancak, düzeltmeyi (kod değişikliğini) hak edip etmediği bağlama bağlıdır.

Veritabanlarının zaman karmaşıklığını artırmak için birçok araç sağladığını unutmayın. Örneğin, bir veritabanından en iyi N sonucunu almak için şunu söylemeniz yeterlidir. Verimsiz çamuru yerleşik optimize edilmiş aramaya dönüştürürken açıklama gereksiz görünüyor.

Bir kod incelemesini (tartışmayı) hak etmek için ikinci dereceden çalışma zamanına sahip bir algoritmayı dikkate almamın nedeni, yavaş olduğu için (yavaş göreceli; kareli üstel ile karşılaştırıldığında hızlıdır) değil, insan sezgisi (müşterileriniz veya diğer programcılar) günlük yaşamdan beklentilerin karıştırılması nedeniyle doğrusal çalışma süresinden çok farklı bir yazılım işlevselliğinden rahatsız olurlar.

Yazılım performansı ile ilgili birçok müşteri şikayeti bu iki kategoriye girmektedir:

• Tüm sistem (yazılım ve donanım) tahmini kullanıma göre belirlenmiştir. Geçen hafta, her şey yolunda gidiyor, belirli bir işlevsellik 5 saniyeden az sürdü. Bu hafta, bir güncelleme yükledikten sonra aynı işlevsellik 1 dakikadan fazla sürüyor.

  • Bu, daha önce karşılaştırılmış bir performansla yapılan bir karşılaştırmadır. Müşteri, gelecekteki performansı bir insan zaman ölçeğinin mutlak ölçüsüne sahiptir (saniyelerden dakikaya).

• Sisteme 100 iş gönderdim. Tek bir iş için geçen süreye kıyasla neden işlenmesi 400 kat sürüyor?

  • Müşteri işlem süresinin doğrusal olmasını beklemektedir. Aslında, müşteri doğrusaldan daha yavaş görevler olduğunu anlayamaz veya kabul edemez.

Bu nedenle, müşteri her ikisi de doğruysa yürütme süresini bir hata olarak değerlendirir:

• Doğrusaldan daha yavaş
• Farkedilir (yani, tipik görev boyutları göz önüne alındığında insan zaman aralığına (saniye veya dakikadan daha uzun) düşer)

İkinci dereceden bir çalışma zamanı algoritmasının sorun oluşturmadığını (yani bir kod değişikliğini hak etmediğini) açıklayan meşru argümanlar:

• Bu ikinci dereceden çalışma zamanı işlevi tarafından işlenen görevin boyutu biraz sınırlıdır
• Tipik boyut aralığı göz önüne alındığında, gerçek (mutlak) yürütme süresi hala reddedilecek kadar küçüktür
• Bir kullanıcı gerçekten farkedilebilecek kadar büyük bir görev göndermeye çalışırsa, kullanıcı uzun çalışma süresi hakkında bir uyarı mesajı alır.
• Sistem kullanıcılarının hepsi uzman, bu yüzden ne yaptıklarını biliyorlar. Örneğin, bir API kullanıcılarının API belgelerindeki ince baskıyı okuması gerekir.

Tipik uygulama geliştirme için yararlı olan birçok algoritma aslında lineerden daha yavaştır (sıralamada olduğu gibi çoğunlukla O (N log N)), bu nedenle büyük ölçekli yazılım aslında, yalnızca ilgili parçayı sıralayarak veya benzer etkiyi sağlayan histogram (istatistiksel) filtreleme tekniklerini kullanın.

Bu, yazılım müşterileri için geçerlidir, ancak bir yazılım kitaplığı veya API işlevinin kullanıcılarının da "müşteriler" olduğunu düşünüyorsanız, yanıt yine de geçerli olacaktır.

Orijinal algoritma doğru bir şekilde uygulandıysa (veya ilgisiz olan herhangi bir hata) , "algoritmayı değiştirme" veya "algoritma değiştirme" , çünkü bu değişiklikler tam olarak yaptığınız anlamına gelir; daha önce kullanılan algoritma için farklı zaman karmaşıklığına sahip bir algoritmanın kullanılması.

Önceki zaman karmaşıklığı uygulanmasındaki bir hata nedeniyle olması durumunda (örneğin yanlışlıkla bir dizi üzerinde bir iç döngü başlangıç noktasını sıfırlamak ne olmalıydı O (n) O haline geldiğini (n bunu söylemek ² sonra)) "sabitleme ikinci dereceden maliyet hatası " veya benzeri.

Bir çakışma var, böyle bir durumda, işin O (n) zamanında yapılabileceğini ve O (n ² ) süresinin bir hata olduğunu biliyorsanız, kod üzerindeki etki aynıdır veya önce kasıtlı olarak O (n ² ) zamanında uyguladınız ve daha sonra başlangıç ​​noktasını sıfırlamadan yine de doğru çalışacağını fark ettiniz ve böylece O (n ² ) için bir O (n) algoritmasının yerini aldınız .

Bir sipariş / büyüklük siparişleri ile hız optimizasyonu. Bu matematiksel olarak yanlış bir dil olmasına rağmen, Düzenin değiştirilme fikrini en iyi şekilde aktarır.

Ölçeklenebilirlik geliştirildi. duydum.