Önemsiz olmayan koşullu ifadeler, döngülerin başlangıç ​​bölümüne taşınmalı mıdır?

Bu fikri stackoverflow.com adresinde aldım.

Aşağıdaki desen yaygındır:

final x = 10;//whatever constant value
for(int i = 0; i < Math.floor(Math.sqrt(x)) + 1; i++) {
  //...do something
}

Yapmaya çalıştığım nokta koşullu ifade karmaşık bir şey ve değişmez.

Bunu, döngünün başlangıç ​​bölümünde belirtmek daha doğru olur mu?

final x = 10;//whatever constant value
for(int i = 0, j = Math.floor(Math.sqrt(x)) + 1; i < j; i++) {
  //...do something
}

Bu daha açık mı?

Koşullu ifade gibi basit ise ne

final x = 10;//whatever constant value
for(int i = 0, j = n*n; i > j; j++) {
  //...do something
}

Ne yapardım böyle bir şey:

void doSomeThings() {
    final x = 10;//whatever constant value
    final limit = Math.floor(Math.sqrt(x)) + 1;
    for(int i = 0; i < limit; i++) {
         //...do something
    }
}

Dürüst olmak gerekirse, başlatmanın j(şimdi limit) döngü başlığına tıklanmasının tek iyi nedeni, onu doğru şekilde kapsam içinde tutmaktır. Olmayan bir sorun yapmak için gereken tüm güzel bir sıkı kapsama alanı.

Hızlı olma arzusunu takdir edebilirim ama okunabilirliği gerçekten iyi bir sebep olmadan feda etmeyin.

Tabi, derleyici optimize edebilir, çoklu varyasyonları başlatmak yasal olabilir, ancak döngüler olduğu gibi hata ayıklamak için yeterince zordur. Lütfen insanlara karşı nazik olun. Bu gerçekten bizi yavaşlatıyor gibi görünüyorsa onu düzeltecek kadar iyi anlamak güzel.

İyi bir derleyici her iki şekilde de aynı kodu üretecektir, bu nedenle performansa gidecekseniz, yalnızca kritik bir döngüdeyseniz ve aslında onu profillendirdiyseniz ve bir fark yarattığını tespit ettiyseniz, değişiklik yapın. Derleyici bunu optimize edemese bile, insanlar işlev çağrılarıyla ilgili durumdaki yorumlarda da belirtildiği gibi, çoğu durumda, performans farkı bir programcının göz önünde bulundurması için çok küçük olacaktır.

Ancak...

Kuralların öncelikle insanlar arasında bir iletişim aracı olduğunu ve her iki seçeneğinizin de diğer insanlarla çok iyi iletişim kurmadığını unutmamalıyız. Birincisi, her yinelemede ifadenin hesaplanması gerektiği izlenimini verir ve ikincisi, başlangıç ​​bölümünde olmak, döngünün içinde bir yerde güncelleneceği anlamına gelir.

Aslında döngünün üstüne çıkarılmasını finalve kodu okuyan herkes için derhal ve bolca anlaşılır olmasını sağlamak isterdim . Bu, ya değişkenin kapsamını arttırdığı için ideal değildir, ancak çevreleme işleviniz zaten bu döngüden daha fazlasını içermemelidir.

@Karl Bielefeldt'in cevabında dediği gibi, bu genellikle sorun değil.

Bununla birlikte, bir zamanlar C ve C ++ 'da yaygın bir sorun olmuştur ve bir hile, kodu okunabilirliği azaltmadan bu konuyu adım adım atmak için bir numara ortaya çıkmıştır - geriye doğru tekrar eder0 .

final x = 10;//whatever constant value
for(int i = Math.floor(Math.sqrt(x)); i >= 0; i--) {
  //...do something
}

Şimdi her yinelemede şartlı >= 0olan, her derleyicinin 1 veya 2 montaj talimatında derleneceği şarttır . Son birkaç on yılda yapılan her CPU bunun gibi temel kontrollere sahip olmalıdır; x64 makinemde hızlı bir kontrol yaparken bunun tahmin edilebilir şekilde cmpl $0x0, -0x14(%rbp)(uzun-int-karşılaştırma değeri 0'a karşılık rbp offsetted -14) dönüştüğünü ve jl 0x100000f59(önceki karşılaştırma “2nd-arg için doğruysa, döngüyü izleyen talimatlara atladığını” görüyorum. <1-arg ”) .

Not I kaldırıldı + 1arasından Math.floor(Math.sqrt(x)) + 1; Matematiğin çalışabilmesi için başlangıç ​​değeri olmalıdır int i = «iterationCount» - 1. Ayrıca dikkat edilmesi gereken, yineleyicinizin imzalanması gerektiğidir; unsigned intçalışmayacak ve büyük olasılıkla derleyici-uyaracak.

~ 20 yıl boyunca C tabanlı dillerde programlama yaptıktan sonra, şimdi ileriye dönük yineleme yapmak için belirli bir neden olmadıkça, yalnızca ters-dizin-yineleme döngüleri yazıyorum. Koşullardaki daha basit kontrollere ek olarak, ters-yineleme de sıklıkla, yinelenen sırada mutasyona uğrayan dizi mutasyonlarının ne olacağı konusunda yan adımlara yol açar.

Math.sqrt (x) Mymodule.SomeNonPureMethodWithSideEffects (x) ile değiştirilince ilginçleşir.

Temelde benim modus operandi'm şudur: eğer bir şeyin daima aynı değeri vermesi bekleniyorsa, o zaman sadece bir kez değerlendirin. Örneğin List.Count, listenin döngünün çalışması sırasında değişmemesi gerekiyorsa, döngünün dışındaki sayımı başka bir değişkene getirin.

Bu "sayımların" bir kısmı özellikle veritabanlarıyla uğraşırken şaşırtıcı şekilde pahalı olabilir. Listenin yinelenmesi sırasında değişmesi gerekmeyen bir veri kümesi üzerinde çalışıyor olsanız bile.

Bence bu çok dile özgü. Örneğin, eğer C ++ 11 kullanıyorsanız, durum kontrolü bir constexprfonksiyon ise, derleyicinin her seferinde aynı değeri vereceğini bildiği için birden fazla işlemi optimize etme ihtimalinin yüksek olacağından şüpheleniyorum .

Bununla birlikte, eğer işlev çağrısı constexprderleyici olmayan bir kütüphane işlevi ise , hemen hemen kesinlikle her yinelemede uygulayacaktır (inline olmadığı ve bu nedenle saf olarak çıkarılabildiği sürece).

Java hakkında daha az şey biliyorum ama bu JIT'ye derlendiğinde, derleyicinin çalışma zamanında muhtemel satır içi ve durumu iyileştirmek için yeterli bilgiye sahip olduğunu tahmin ediyorum. Fakat bu iyi bir derleyici tasarımına bağlı olacaktır ve bu döngüyü belirleyen derleyici, yalnızca tahmin edebileceğimiz bir optimizasyon önceliğidir.

Şahsen, eğer mümkünse for döngüsünün içine konmanın konulmasının biraz daha zarif olduğunu hissediyorum, ancak eğer karmaşıksa bunu bir constexprveya inlinefonksiyona yazacağım ya da dilleriniz, işlevin saf ve iyimser olduğunu ima edecek kadar eşdeğer. Bu, amacı belirgin hale getirir ve büyük bir okunamayan çizgi oluşturmadan deyimsel döngü stilini korur. Ayrıca, eğer kendi işlevi varsa, durum kontrolüne bir isim verir, böylece okuyucular karmaşıksa okumadan kontrolün ne olduğunu mantıklı bir şekilde görebilirler.