เคล็ดลับการเพิ่มประสิทธิภาพระดับต่ำ C ++ [ปิด]

สมมติว่าคุณมีอัลกอริธึมที่ดีที่สุดแล้วโซลูชันระดับต่ำสุดที่คุณสามารถเสนอได้สำหรับการบีบอัตราเฟรม Sweet Sweet สองสามหยดสุดท้ายของรหัส C ++ คืออะไร

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

ปรับโครงร่างข้อมูลของคุณให้เหมาะสม! (สิ่งนี้ใช้ได้กับภาษามากกว่าภาษา C ++)

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

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

วิธีนี้เมื่อ CPU ดึงข้อมูลสำหรับการวนซ้ำครั้งแรกของลูปของคุณการทำซ้ำหลาย ๆ ค่าของข้อมูลถัดไปจะถูกโหลดลงในแคชด้วย

จริงๆ CPU เร็วและคอมไพเลอร์ดี ไม่มีอะไรมากที่คุณสามารถทำได้ด้วยการใช้คำสั่งที่น้อยลงและเร็วขึ้น การเชื่อมโยงกันแคชเป็นที่ที่ (เป็นบทความสุ่ม I Googled - มันมีตัวอย่างที่ดีของการเชื่อมโยงกันแคชสำหรับอัลกอริทึมที่ไม่เพียงวิ่งผ่านข้อมูลเชิงเส้น)

เคล็ดลับระดับต่ำมาก ๆ แต่เป็นเคล็ดลับที่มีประโยชน์:

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

if(__builtin_expect(entity->extremely_unlikely_flag, 0)) {
  // code that is rarely run
}

ฉันเห็นความเร็ว 10-20% พร้อมการใช้งานที่เหมาะสม

สิ่งแรกที่คุณต้องเข้าใจคือฮาร์ดแวร์ที่คุณใช้อยู่ มันจัดการกับการแตกกิ่งได้อย่างไร แล้วแคชล่ะ มีชุดคำสั่ง SIMD หรือไม่ สามารถใช้โปรเซสเซอร์ได้กี่ตัว ต้องแชร์เวลาตัวประมวลผลกับสิ่งอื่นหรือไม่

คุณอาจแก้ปัญหาเดียวกันในวิธีที่แตกต่างกันมาก - แม้แต่ตัวเลือกของอัลกอริทึมของคุณควรขึ้นอยู่กับฮาร์ดแวร์ ในบางกรณี O (N) สามารถทำงานช้ากว่า O (NlogN) (ขึ้นอยู่กับการใช้งาน)

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

รายละเอียดแล้ว โปรไฟล์, โปรไฟล์, โปรไฟล์ ดูการใช้งานหน่วยความจำดูบทลงโทษการแยก, ดูค่าใช้จ่ายการเรียกใช้ฟังก์ชัน, ดูการใช้ไปป์ไลน์ หาสิ่งที่ทำให้โค้ดของคุณช้าลง อาจเป็นการเข้าถึงข้อมูล (ฉันเขียนบทความชื่อ "The Latency Elephant" เกี่ยวกับค่าใช้จ่ายในการเข้าถึงข้อมูล - google it ฉันไม่สามารถโพสต์ลิงก์ 2 ลิงก์ที่นี่เนื่องจากฉันไม่มี "ชื่อเสียง" เพียงพอ) ตรวจสอบอย่างละเอียดและ จากนั้นปรับโครงร่างข้อมูลของคุณ (อาเรย์ที่เป็นเนื้อเดียวกันขนาดใหญ่ที่ยอดเยี่ยมนั้นยอดเยี่ยมมาก ) และการเข้าถึงข้อมูล

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

หากคุณยังต้องการความเร็วมากกว่านี้ให้ขนานกันไป หากคุณได้รับประโยชน์จากการทำงานบน PS3 แล้ว SPU นั้นเป็นเพื่อนของคุณ ใช้พวกเขารักพวกเขา หากคุณเขียนโซลูชัน SIMD อยู่แล้วคุณจะได้รับผลประโยชน์มหาศาลจากการเข้า SPU

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

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

แล้วโปรไฟล์อีกครั้ง

ขั้นแรก: คิดอย่างรอบคอบเกี่ยวกับข้อมูลของคุณเกี่ยวกับอัลกอริทึมของคุณ O (บันทึก n) ไม่ได้เร็วกว่า O (n) เสมอไป ตัวอย่างง่ายๆ: ตารางแฮชที่มีเพียงไม่กี่คีย์มักจะถูกแทนที่ดีกว่าด้วยการค้นหาแบบเชิงเส้น

ขั้นตอนที่สอง: ดูชุดประกอบที่สร้างขึ้น C ++ นำการสร้างรหัสโดยนัยจำนวนมากมาสู่ตาราง บางครั้งมันย่องเข้าหาคุณโดยที่คุณไม่รู้

แต่สมมติว่าเป็นเวลาถีบไปถึงโลหะจริงๆ: โปรไฟล์ อย่างจริงจัง. การใช้ "เทคนิคการปฏิบัติงาน" แบบสุ่มเกี่ยวกับโอกาสที่จะเจ็บปวดอย่างที่มันควรจะช่วย

จากนั้นทุกอย่างขึ้นอยู่กับว่าปัญหาคอขวดของคุณคืออะไร

data cache คิดถึง => ปรับโครงร่างข้อมูลของคุณให้เหมาะสม นี่เป็นจุดเริ่มต้นที่ดี: http://gamesfromwithin.com/data-oriented-design

คิดถึงรหัสแคช => ดูการเรียกฟังก์ชันเสมือนความลึก callstack ที่มากเกินไปสาเหตุที่พบบ่อยสำหรับประสิทธิภาพที่ไม่ดีคือความเชื่อที่ผิดพลาดที่คลาสพื้นฐานต้องเป็นเสมือน

C ++ ประสิทธิภาพทั่วไปอื่น ๆ

• การจัดสรร / การจัดสรรคืนมากเกินไป หากประสิทธิภาพนั้นสำคัญอย่าเรียกใช้ในรันไทม์ เคย
• คัดลอกสิ่งก่อสร้าง หลีกเลี่ยงทุกที่ที่คุณสามารถ ถ้ามันสามารถอ้างอิง const, ทำให้มันเป็นหนึ่ง

ทุกอย่างที่กล่าวมาข้างต้นชัดเจนเมื่อคุณดูที่ชุมนุม

ลบสาขาที่ไม่จำเป็น

ในบางแพลตฟอร์มและคอมไพเลอร์บางสาขาอาจทิ้งท่อทั้งหมดของคุณดังนั้นแม้ไม่มีนัยสำคัญหากบล็อก () อาจมีราคาแพง

PowerPC สถาปัตยกรรม (PS3 / X360) fselมีคำแนะนำเลือกจุดลอยตัว สิ่งนี้สามารถนำมาใช้ในสถานที่ของสาขาได้หากบล็อกนั้นเป็นงานที่ได้รับมอบหมายอย่างง่าย:

float result = 0;
if (foo > bar) { result = 2.0f; }
else { result = 1.0f; }

กลายเป็น:

float result = fsel(foo-bar, 2.0f, 1.0f);

เมื่อพารามิเตอร์แรกมากกว่าหรือเท่ากับ 0 พารามิเตอร์ที่สองจะถูกส่งกลับมิฉะนั้นเป็นพารามิเตอร์ที่สาม

ราคาของการสูญเสียสาขาคือทั้งถ้า {} และบล็อกอื่น {} จะถูกดำเนินการดังนั้นหากหนึ่งคือการดำเนินการที่มีราคาแพงหรือ dereferences ตัวชี้ NULL การเพิ่มประสิทธิภาพนี้ไม่เหมาะ

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

นี่คือข้อมูลเพิ่มเติมเกี่ยวกับการแตกแขนงและเฟ็ล:

http://assemblyrequired.crashworks.org/tag/intrinsics/

หลีกเลี่ยงการเข้าถึงหน่วยความจำและสุ่มโดยเฉพาะอย่างยิ่งค่าใช้จ่ายทั้งหมด

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

คุณยังสามารถอ่านกฎนี้ด้วยวิธีอื่น ๆ : ทำการคำนวณให้มากที่สุดเท่าที่จะทำได้ระหว่างการเข้าถึงหน่วยความจำ

ใช้ Compiler Intrinsics

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

นี่คือข้อมูลอ้างอิงสำหรับ Visual Studioและนี่คือข้อมูลอ้างอิงสำหรับ GCC

ลบการเรียกใช้ฟังก์ชันเสมือนที่ไม่จำเป็น

การจัดส่งฟังก์ชั่นเสมือนอาจช้ามาก นี้บทความให้คำอธิบายที่ดีว่าทำไม หากเป็นไปได้สำหรับฟังก์ชั่นที่เรียกว่าหลาย ๆ ครั้งต่อเฟรมให้หลีกเลี่ยง

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

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

หลักการพื้นฐานของฉันคือไม่ได้ทำอะไรที่ไม่จำเป็น

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

นี่ไม่ได้แปลว่าคุณกำลังใช้อัลกอริทึมที่ไม่ดี มันอาจหมายความว่าคุณกำลังเรียกใช้การคำนวณทุกเฟรมที่อาจถูกแคชเป็นระยะเวลาสั้น ๆ (หรือคำนวณล่วงหน้าทั้งหมด)

ฉันมักจะลองวิธีนี้ก่อนที่จะพยายามเพิ่มประสิทธิภาพในระดับต่ำจริงๆ

ใช้ SIMD (โดย SSE) หากคุณยังไม่ได้ดำเนินการ Gamasutra มีดีบทความเกี่ยวกับเรื่องนี้ คุณสามารถดาวน์โหลดซอร์สโค้ดได้จากไลบรารี่ที่นำเสนอในตอนท้ายของบทความ

ลดการพึ่งพาเครือข่ายเพื่อใช้ CPU pipleline ให้ดีขึ้น

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

ตัวอย่าง:

float *data = ...;
int length = ...;

// Slow version
float total = 0.0f;
int i;
for (i=0; i < length; i++)
{
  total += data[i]
}

// Fast version
float total1, total2, total3, total4;
for (i=0; i < length-3; i += 4)
{
  total1 += data[i];
  total2 += data[i+1];
  total3 += data[i+2];
  total4 += data[i+3];
}
for (; i < length; i++)
{
  total += data[i]
}
total += (total1 + total2) + (total3 + total4);

อย่ามองข้ามคอมไพเลอร์ของคุณ - หากคุณใช้ gcc บน Intel คุณสามารถเพิ่มประสิทธิภาพได้อย่างง่ายดายโดยเปลี่ยนไปใช้ตัวรวบรวม Intel C / C ++ หากคุณกำลังกำหนดเป้าหมายแพลตฟอร์ม ARM ให้ตรวจสอบคอมไพเลอร์เชิงพาณิชย์ของ ARM หากคุณอยู่บน iPhone แอปเปิ้ลอนุญาตให้ใช้เสียงดังกราวเริ่มต้นด้วย iOS 4.0 SDK

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

คำแนะนำที่ดีที่สุดของฉันคือละเว้นการปรับให้เหมาะสมในระดับต่ำและมุ่งเน้นที่ระดับที่สูงกว่า คอมไพเลอร์และ CPU ไม่สามารถเปลี่ยนอัลกอริทึมของคุณจาก O (n ^ 2) เป็นอัลกอริทึม O (1) ไม่ว่าพวกเขาจะได้รับผลดีเพียงใด นั่นจะทำให้คุณต้องมองสิ่งที่คุณพยายามทำและหาวิธีที่ดีกว่าที่จะทำ ให้คอมไพเลอร์และ CPU กังวลเกี่ยวกับระดับต่ำและคุณมุ่งเน้นไปที่ระดับกลางถึงระดับสูง

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

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

ในทางเทคนิค 'จำกัด ' ไม่มีอยู่ใน C ++ มาตรฐาน แต่มีรายการเทียบเท่าเฉพาะแพลตฟอร์มสำหรับคอมไพเลอร์ C ++ ส่วนใหญ่ดังนั้นจึงควรพิจารณา

ดูเพิ่มเติมที่: http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-restrict-keyword.html

เตรียมทุกอย่าง!

ข้อมูลเพิ่มเติมที่คุณให้คอมไพเลอร์เกี่ยวกับข้อมูลการเพิ่มประสิทธิภาพที่ดีขึ้นคือ (อย่างน้อยก็ในประสบการณ์ของฉัน)

void foo(Bar * x) {...;}

กลายเป็น;

void foo(const Bar * const x) {...;}

คอมไพเลอร์รู้แล้วว่าตัวชี้ x จะไม่เปลี่ยนแปลงและข้อมูลที่ชี้ไปจะไม่เปลี่ยนแปลงเช่นกัน

สิทธิประโยชน์อื่น ๆ เพิ่มเติมคือคุณสามารถลดจำนวนข้อผิดพลาดโดยไม่ได้ตั้งใจหยุดตัวเอง (หรืออื่น ๆ ) แก้ไขสิ่งที่พวกเขาไม่ควร

วิธีที่ดีที่สุดในการเพิ่มประสิทธิภาพคือการเปลี่ยนอัลกอริทึมของคุณ การใช้งานทั่วไปที่น้อยกว่ายิ่งคุณเข้าใกล้โลหะมากขึ้นเท่านั้น

สมมติว่าทำไปแล้ว ....

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

หลีกเลี่ยงแคชคิดถึง กระบวนการแบทช์ให้มากที่สุดเท่าที่จะทำได้ หลีกเลี่ยงฟังก์ชั่นเสมือนและทางอ้อมอื่น ๆ

ในที่สุดวัดทุกอย่าง กฎการเปลี่ยนแปลงตลอดเวลา สิ่งที่เคยเพิ่มความเร็วรหัส 3 ปีที่ผ่านมาตอนนี้ช้าลง ตัวอย่างที่ดีคือ 'ใช้ฟังก์ชั่นคณิตศาสตร์คู่แทนรุ่นลอย' ฉันจะไม่ได้ตระหนักถึงสิ่งนั้นหากฉันไม่ได้อ่าน

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

แก้ไขเพื่ออธิบายว่าทำไมไม่มีการเริ่มต้นเริ่มต้น: รหัสจำนวนมากพูดว่า: Vector3 bla; bla = DoSomething ();

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

Vector3 bla (noInit); bla = doSomething ();

ลดการประเมินผลนิพจน์แบบบูล

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

if ((foo && bar) || blah) { ... } 

กลายเป็น:

if ((foo & bar) | blah) { ... }

ใช้เลขคณิตเลขจำนวนเต็มแทน หาก foos และ bar ของคุณเป็นค่าคงที่หรือถูกประเมินก่อน if () ค่านี้อาจเร็วกว่าเวอร์ชันบูลีนปกติ

โบนัสเป็นเวอร์ชันทางคณิตศาสตร์ที่มีสาขาน้อยกว่าเวอร์ชันบูลีนทั่วไป ซึ่งเป็นวิธีการอื่นเพิ่มประสิทธิภาพ

ข้อเสียที่ยิ่งใหญ่คือการที่คุณสูญเสียการประเมินผลขี้เกียจ - foo != NULL & foo->dereference()บล็อกทั้งมีการประเมินเพื่อให้คุณไม่สามารถทำ ด้วยเหตุนี้จึงพิสูจน์ได้ว่านี่เป็นเรื่องยากที่จะรักษาและการแลกเปลี่ยนอาจจะดีเกินไป

คอยดูการใช้งานสแต็กของคุณ

ทุกสิ่งที่คุณเพิ่มลงในสแต็กเป็นการเพิ่มและสร้างพิเศษเมื่อเรียกใช้ฟังก์ชัน เมื่อจำเป็นต้องใช้พื้นที่สแต็คจำนวนมากในบางครั้งอาจเป็นประโยชน์ในการจัดสรรหน่วยความจำในการทำงานล่วงหน้าและหากแพลตฟอร์มที่คุณใช้งานอยู่มี RAM ที่รวดเร็วสำหรับการใช้งาน - ทั้งหมดนั้นดีกว่า!