ควรย้ายเงื่อนไขที่ไม่น่าสนใจไปยังส่วนเริ่มต้นของลูปหรือไม่?

ฉันได้ความคิดนี้จากคำถามนี้ใน stackoverflow.com

รูปแบบต่อไปนี้เป็นเรื่องธรรมดา:

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

จุดที่ฉันพยายามทำคือข้อความที่มีเงื่อนไขเป็นเรื่องที่ซับซ้อนและไม่เปลี่ยนแปลง

มันเป็นการดีกว่าที่จะประกาศในส่วนเริ่มต้นของลูปเช่นนี้?

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

ชัดเจนกว่านี้ไหม

เกิดอะไรขึ้นถ้านิพจน์เงื่อนไขนั้นง่ายเช่น

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

สิ่งที่ฉันทำคืออะไรเช่นนี้:

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
    }
}

สุจริตเหตุผลเดียวที่ดีในการเริ่มต้นการบีบอัดj(ตอนนี้limit) ลงในส่วนหัวของลูปคือการกำหนดขอบเขตอย่างถูกต้อง ทั้งหมดที่ใช้เพื่อทำให้ปัญหาที่ไม่ได้เป็นขอบเขตการปิดล้อมที่ดี

ฉันสามารถชื่นชมความต้องการที่จะเร็ว แต่อย่าเสียสละความสามารถในการอ่านโดยไม่มีเหตุผลที่ดี

แน่นอนว่าคอมไพเลอร์อาจปรับให้เหมาะสมการกำหนดค่าเริ่มต้นหลาย vars อาจถูกกฎหมาย แต่ลูปนั้นยากพอที่จะทำการดีบักอย่างที่มันเป็น กรุณาใจดีกับมนุษย์ ถ้าสิ่งนี้ทำให้เราช้าลงจริง ๆ ก็เป็นเรื่องดีที่ได้เข้าใจมันเพียงพอที่จะแก้ไข

คอมไพเลอร์ที่ดีจะสร้างโค้ดเดียวกันด้วยวิธีใดวิธีหนึ่งดังนั้นหากคุณต้องการประสิทธิภาพให้ทำการเปลี่ยนแปลงหากมันอยู่ในลูปวิกฤติและคุณได้ทำโปรไฟล์จริงและพบว่ามันสร้างความแตกต่าง แม้ว่าคอมไพเลอร์จะไม่สามารถปรับให้เหมาะสมเพราะคนได้ชี้ให้เห็นในความคิดเห็นเกี่ยวกับกรณีที่มีการเรียกใช้ฟังก์ชั่นในสถานการณ์ส่วนใหญ่ความแตกต่างของประสิทธิภาพจะเล็กเกินไปที่จะคุ้มค่ากับการพิจารณาของโปรแกรมเมอร์

อย่างไรก็ตาม ...

เราต้องไม่ลืมว่ารหัสนั้นเป็นสื่อกลางในการสื่อสารระหว่างมนุษย์และตัวเลือกของคุณทั้งสองไม่สามารถสื่อสารกับมนุษย์คนอื่นได้เป็นอย่างดี อันแรกให้ความรู้สึกว่านิพจน์จะต้องคำนวณทุกครั้งและส่วนที่สองในส่วนเริ่มต้นบอกเป็นนัยว่ามันจะได้รับการปรับปรุงที่ไหนสักแห่งในวงที่มันคงที่ตลอด

ฉันอยากจะดึงมันออกมาเหนือลูปและfinalทำให้มันชัดเจนขึ้นอย่างทันทีทันใดสำหรับทุกคนที่อ่านโค้ด ไม่เหมาะอย่างยิ่งเนื่องจากจะเป็นการเพิ่มขอบเขตของตัวแปร แต่ฟังก์ชันการล้อมรอบของคุณไม่ควรมีมากไปกว่าการวนซ้ำนั้น

ดังที่ @Karl Bielefeldt พูดในคำตอบของเขานี่มักจะไม่ใช่ปัญหา

แต่ก็เป็นช่วงเวลาหนึ่งที่เป็นปัญหาที่พบบ่อยใน C และ C ++ และเคล็ดลับมาเกี่ยวกับไปทางด้านขั้นตอนการแก้ไขปัญหาโดยไม่ต้องลดรหัส readability- ย้ำถอยหลังลงไป0

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

ตอนนี้เงื่อนไขในการวนซ้ำทุกครั้งเป็นเพียง>= 0ที่คอมไพเลอร์ทุกคนจะรวบรวมเป็น 1 หรือ 2 คำแนะนำการชุมนุม ซีพียูทุกตัวในช่วงสองสามทศวรรษที่ผ่านมาควรมีการตรวจสอบขั้นพื้นฐานเช่นนี้ ทำการตรวจสอบอย่างรวดเร็วบนเครื่อง x64 ของฉันฉันเห็นสิ่งนี้กลายเป็นสิ่งที่คาดการณ์ได้cmpl $0x0, -0x14(%rbp)(ค่า long-int- เปรียบเทียบ 0 เทียบกับ register rbp offsetted -14) และjl 0x100000f59(ข้ามไปยังคำสั่งต่อไปนี้ลูปถ้าการเปรียบเทียบก่อนหน้านี้เป็นจริงสำหรับ <1st-หาเรื่อง”)

โปรดทราบว่าฉันลบออก+ 1จากMath.floor(Math.sqrt(x)) + 1; int i = «iterationCount» - 1เพื่อให้ทางคณิตศาสตร์ที่จะออกมาทำงานค่าเริ่มต้นควรจะเป็น สิ่งที่ควรสังเกตคือตัววนซ้ำของคุณต้องลงนาม unsigned intจะไม่ทำงานและน่าจะคอมไพเลอร์เตือน

หลังจากการเขียนโปรแกรมในภาษาที่ใช้ภาษา C เป็นเวลา ~ 20 ปีตอนนี้ฉันเขียนลูปย้อนกลับดัชนีซ้ำแล้วซ้ำอีกเว้นแต่มีเหตุผลเฉพาะในการส่งต่อดัชนีซ้ำ นอกจากการตรวจสอบที่ง่ายกว่าในเงื่อนไขแล้วการทำซ้ำย้อนกลับยังมักจะทำตามขั้นตอนด้านที่จะทำให้เกิดการกลายพันธุ์ของอาร์เรย์ในขณะที่ทำซ้ำ

มันน่าสนใจเมื่อ Math.sqrt (x) ถูกแทนที่ด้วย Mymodule.SomeNonPureMethodWithSideEffects (x)

โดยทั่วไปตัวถูกดำเนินการ modus ของฉันคือ: หากสิ่งที่คาดว่าจะให้ค่าเดียวกันเสมอแล้วประเมินเพียงครั้งเดียว ตัวอย่างเช่น List.Count หากรายการไม่ควรเปลี่ยนระหว่างการดำเนินการของลูปดังนั้นให้นับจำนวนภายนอกลูปเป็นตัวแปรอื่น

"จำนวน" เหล่านี้บางอย่างอาจมีราคาแพงโดยเฉพาะอย่างยิ่งเมื่อคุณจัดการกับฐานข้อมูล แม้ว่าคุณกำลังทำงานกับชุดข้อมูลที่ไม่ควรเปลี่ยนแปลงในระหว่างการวนซ้ำของรายการ

ในความเห็นของฉันนี่เป็นภาษาเฉพาะสูง ตัวอย่างเช่นหากใช้ C ++ 11 ฉันจะสงสัยว่าถ้าการตรวจสอบเงื่อนไขเป็นconstexprฟังก์ชันคอมไพเลอร์จะมีแนวโน้มที่จะปรับการประมวลผลหลายครั้งให้เหมาะสมเพราะมันรู้ว่ามันจะให้ค่าเดียวกันทุกครั้ง

อย่างไรก็ตามถ้าการเรียกฟังก์ชันเป็นฟังก์ชันไลบรารีที่ไม่ใช่constexprตัวแปลภาษานั้นจะดำเนินการในทุก ๆ การวนซ้ำเนื่องจากมันไม่สามารถอนุมานได้ (ยกเว้นว่าเป็นแบบอินไลน์

ฉันรู้น้อยเกี่ยวกับ Java แต่เนื่องจากเป็น JIT ที่คอมไพล์ฉันคาดเดาว่าคอมไพเลอร์มีข้อมูลเพียงพอที่รันไทม์เพื่ออินไลน์ที่เป็นไปได้และปรับเงื่อนไขให้เหมาะสม แต่สิ่งนี้จะขึ้นอยู่กับการออกแบบคอมไพเลอร์ที่ดีและคอมไพเลอร์ที่ตัดสินใจว่าการวนซ้ำนี้เป็นการเพิ่มประสิทธิภาพเบื้องต้นที่เราคาดเดาได้เท่านั้น

โดยส่วนตัวแล้วฉันรู้สึกว่ามันดีกว่าการใส่เงื่อนไขไว้ในลูปถ้าคุณทำได้ แต่ถ้ามันซับซ้อนฉันจะเขียนมันลงในฟังก์ชั่นconstexprหรือinlineฟังก์ชั่นหรือภาษาของคุณเทียบเท่ากับคำใบ้ว่าฟังก์ชั่นนั้นบริสุทธิ์และเหมาะสมที่สุด สิ่งนี้ทำให้เจตนาชัดเจนและรักษาสไตล์วนซ้ำโดยไม่สร้างบรรทัดที่อ่านไม่ได้ขนาดใหญ่ นอกจากนี้ยังให้เงื่อนไขการตรวจสอบชื่อถ้ามันเป็นฟังก์ชั่นของตัวเองเพื่อให้ผู้อ่านสามารถเห็นเหตุผลในทันทีสิ่งที่ตรวจสอบมีไว้สำหรับโดยไม่ต้องอ่านมันถ้าซับซ้อน