Hızlı ve rahatsız etmiyor musun?


9

Özellikle 'standart' (HPC olmayan) uygulamalar yazarken, hangi sıralama algoritmasını seçeceğinizi mi yoksa hızlı sıralama ile yerleştiğinizi (çoğu kütüphanenin sıralama olarak adlandırdığı şey) düşünüyor musunuz? Bir dereceye kadar belirli durumlarda karlı olabilir, ancak diğer taraftan uygun optimizasyon, sorunu analiz etmek ve kıyaslamalar yapmak için biraz zaman gerektirir.

Yanıtlar:


12

Genel olarak, daha egzotik bir şey yapmak için özel bir ihtiyaç olmadıkça varsayılan yöntemleri kullanmak, her şeyi IMHO'da çok daha okunabilir / anlaşılabilir tutar.

Karmaşıklık ekleme zamanı olan bir performans sorununuz olduğunu (veya bazı durumlarda kesinlikle şüpheleniyorsanız) deneyimliyorsanız.

Öte yandan, sıralamanız gereken nesneler için yerleşik bir tür olmadığından yeterince düşük bir dil kullanıyorsanız, tüm üslerinizi kapsayan bir veya iki tane seçmeye ve bunları uygulamaya çalışın.


6

Bunu yapmamak için çok, çok iyi bir nedeniniz yoksa (ve neden böyle olduğunu belgelemeniz gerekiyorsa) her zaman verilen kütüphane rutinlerini arayın .

Bunun nedeni, sıralama algoritmalarının kesinlikle doğru olması zor olmasıdır. Java quicksort'ta çok büyük veri kümeleriyle bir hata oluştu, bu da Sun tarafından tanımlandı, sabitlendi ve müşterilere teslim edildi, bu yüzden zorunda kalmadınız.

Ayrıca Java 7'deki varsayılan sıralama daha yeni ve daha iyi bir sıralamaya yükseltildi. Ayrıca ücretsiz.

Varsayılan sıralama sizin için yeterince iyi değilse , buna uyun .


3

Bir konferansta bir kez bunun hakkında güzel bir hikaye duydum.

Microsoft'ta bir kişi bir VB uygulaması (c. VB 3) yazıyordu ve bir sürü kişiye bir yük yükü olduğunu söyleyerek bir sürü kişiye mail attı ve siparişte nasıl görünmesi gerektiğine dair birleşik girişte görünmelerini istedi.

Herkes eski bilgisayar bilimleri ders kitaplarına daldı, yüksek verimli rutinleri araştırdı ve Visual Basic'e aktardı ve ona postaladı. Bir adam az önce "birleşik giriş kutusunda kaç değer var?"

"Yaklaşık 50" yanıtı geldi.

Msgstr "Sıralanan özelliği DOĞRU olarak ayarla".

Örneklerin% 99.9999'unda, kütüphane rutini ile yazdığınız her şey arasındaki performans farkı göz ardı edilebilir olacak ve çaba ve bakım yükü sonuçlardan büyük ölçüde ağır basacaktır.


1

Erken optimizasyon ile ilgili klasik alıntıyı çıkarmanın tam zamanı. Çoğu durumda, gerçekten önemli değil. Heck, bu günlerde CPU'ların hızıyla, çoğu veri kümesini kabarcıklandırabilir ve gerçekten fazla farkedemezsiniz. Ancak gerçekten büyük veri kümelerini sıralarken ve sıralama performansı bir sorun olmaya başladığında, kesinlikle diğer seçeneklere bakmalısınız.


Kabarcık sıralaması? Performansı ortalama ve en kötü durum için en kötüsüdür ve en iyi durum için ekleme sıralamasına eşittir. Kullanılması için hiçbir neden yok.
Hippo

1
@Hippo: Aslında kabarcık türünü kullanarak savunmuyordum. Modern bilgisayarların, algoritmanın ne kadar yavaş olduğu önemli olmadığından, kullanıcının fark etmeyeceği kadar hızlı olduğu anlamına geliyordu.
Mason Wheeler

Bogosort'a ne dersin ?
dsimcha

0

Her ne kadar açıkçası bit ve zaman dilimleri için önemli değil. Birleştirme sıralamasının yazım ve anlama açısından çabuk sıralamadan daha kolay olduğunu düşünüyorum. Eğer kendi sıralama algoritmamı yazacaksam, bunu kullanırdım.


Viva birleşiyor! Ve biraz daha iyi bir sabit terim ve korkunç bir kötü durum yok.
Frank Shearar

0

En azından yetkin bir şekilde yazılmış bir kütüphanede, yerleşik olanın bir Quicksort'tan ziyade sortbir Introsort olarak uygulanmasını beklerdim . Fark nadiren çok önemlidir, ancak Introsort, daha yaygın vakalar üzerinde minimum etki ile Quicksort'un kötü kötü performansını ortadan kaldırır.

Ancak, sorunuzu cevaplamak için: evet - genellikle başlamanız gereken şey budur ve bunun bir sorun olduğunu belirten profil sonuçları elde edene kadar / devam edene kadar, burada kalmalıdır.

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.