คุณเพิ่มประสิทธิภาพที่ไหน

มีสองพื้นที่ที่อาจปรับให้เหมาะสมสำหรับความเร็วใน:

• ที่ใช้เวลามากที่สุด
• รหัสที่เรียกว่ามากที่สุด

จุดไหนดีที่สุดในการเริ่มเพิ่มประสิทธิภาพ

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

คุณควรเพิกเฉยประสิทธิภาพเล็ก ๆ น้อย ๆ 95% ของเวลา ก่อนอื่นให้ทำงานอย่างถูกต้องจากนั้นวิเคราะห์ ...

การออกแบบของคุณ

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

ตัวอย่างเช่นในเกม 3 มิติ: หากคุณเริ่มต้นด้วยรายการวัตถุแบบเรียบง่ายสำหรับกราฟฉากของคุณคุณจะเห็นประสิทธิภาพที่ต่ำมากสำหรับวัตถุจำนวนน้อย แต่ถ้าคุณใช้ลำดับชั้นของโวลุ่ม (เช่น octree หรือ BVH) แทนและเลือกส่วนของต้นไม้ในขณะที่วาดคุณจะเห็นประสิทธิภาพที่เพิ่มขึ้นอย่างมาก

เมื่อการออกแบบของคุณดูเหมือนถูกต้องคุณสามารถไปที่ ...

ตรรกะระดับต่ำ

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

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

ก่อนอื่นให้เรียกใช้ตัวสร้างโปรไฟล์เพื่อดูว่ารหัสของคุณใช้เวลาไปที่ใด

จากนั้นดูสถานที่เหล่านั้นเพื่อดูว่าสถานที่ใดเหมาะแก่การปรับให้เหมาะสมที่สุด

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

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

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

แก้ไขเพื่อเพิ่ม: เนื่องจากคุณมีฟังก์ชั่นเฉพาะที่ใช้เวลานานลองทำตามขั้นตอนด้านบนโดยใช้ฟังก์ชั่นเฉพาะนั้นที่กำลังรัน 10 ครั้ง

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

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

ฉันมักจะไม่กังวลเกี่ยวกับสิ่งนี้ (จนกว่าฉันจะต้องทำการปรับแต่งประสิทธิภาพ) เว้นแต่ฉันจะมีความคิดล่วงหน้าว่าจะเกิดอะไรขึ้น

ปกติแล้ว "เรา" จะไม่ปรับให้เหมาะสมจนกว่าจะมีความต้องการการเพิ่มประสิทธิภาพที่ชัดเจนเมื่อบางสิ่งช้า

และเมื่อความต้องการนี้ปรากฎตัวมันมักจะบอกเป็นนัยถึงสิ่งที่เรียกว่าการปรับให้เหมาะสม

ดังนั้นคำตอบจึงเป็นเรื่องปกติ: "ขึ้นอยู่กับ"

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

คุณควรทราบว่าส่วนใดที่ทำให้แคชส่วนใหญ่คิดถึง การรวมรหัสการโทรจะช่วยได้ที่นี่

ปัญหาคือวลี "ที่ใช้เวลามากที่สุด" ไม่ชัดเจน

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

ถ้ามันหมายถึง "ที่ในรหัสของโปรแกรมเมอร์เป็นคำสั่งที่ดำเนินการที่ใช้เวลาส่วนใหญ่" ซึ่งเป็นแนวคิดที่มีประโยชน์มากขึ้น

ปัญหาเกี่ยวกับแนวคิดของ "รหัสที่เรียกว่ามากที่สุด" คือระยะเวลาที่ใช้คือผลคูณของความถี่ที่เรียกใช้และเวลาที่ใช้ในการโทรหนึ่งครั้ง (รวมถึง callees และ I / O) เนื่องจากระยะเวลาที่ใช้อาจแตกต่างกันไปตามขนาดของคำสั่งดังนั้นจำนวนครั้งที่มีการเรียกใช้จึงไม่ได้บอกให้คุณทราบถึงปัญหาที่เกิดขึ้น ฟังก์ชัน A อาจเรียกได้ 10 ครั้งและใช้เวลา 0.1 วินาทีในขณะที่ฟังก์ชัน B อาจเรียกได้ว่า 1,000 ครั้งและใช้เวลาหนึ่งไมโครวินาที

สิ่งหนึ่งที่จะบอกให้คุณดูคือ: เมื่อใดก็ตามที่บรรทัดของโค้ดทำให้เวลาที่ใช้ไปมันจะอยู่บนสแต็ก ตัวอย่างเช่นหากบรรทัดของโค้ดเป็นฮอตสปอตหรือถ้าเป็นการเรียกไปยังฟังก์ชันไลบรารีหรือถ้าเป็นการเรียกที่ 20 ในแผนผังการโทร 30 ระดับหากรับผิดชอบ 20% ของเวลา มันอยู่บนสแต็ก 20% ของเวลา ตัวอย่างแบบสุ่มเวลาของสแต็กแต่ละคนจะมีโอกาส 20% ที่จะแสดงมัน ยิ่งไปกว่านั้นหากตัวอย่างสามารถนำมาใช้ในช่วง I / O พวกเขาจะแสดงให้คุณเห็นว่าบัญชีสำหรับ I / O ซึ่งสามารถสิ้นเปลืองมากขึ้นหรือน้อยลงตามรอบ CPU ที่สูญเปล่า

และนี่เป็นสิ่งที่ไม่ขึ้นกับว่ามีการเรียกใช้กี่ครั้ง

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

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

คุณได้ทำการตรวจวัดเพื่อที่คุณจะได้รู้ว่าโค้ดใดใช้เวลานานที่สุด?

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

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

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

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

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

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

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

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

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

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

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

นอกจากนี้คุณต้องตรวจสอบให้แน่ใจว่าคุณกำลังทำโปรไฟล์ที่สอดคล้องกับสิ่งที่ผู้ใช้ต้องการทำจริง ๆ มิฉะนั้นจะต้องมีระเบียบวินัยและวิทยาศาสตร์ทั้งหมดในการวัดและการเปรียบเทียบของคุณนั้นไม่มีค่าเนื่องจากไม่สอดคล้องกับสิ่งที่ลูกค้าทำกับผลิตภัณฑ์ ฉันมีเพื่อนร่วมงานหนึ่งครั้งที่ปรับนรกจากอัลกอริทึมการแบ่งย่อยเพื่อแบ่งลูกบาศก์ให้เป็นหนึ่งพันล้านแง่มุมและเขามีความภาคภูมิใจอย่างมากในเรื่องนั้น .... ยกเว้นผู้ใช้ที่ไม่แบ่งลูกบาศก์ 6 เหลี่ยมแบบง่ายเป็นพันล้าน แง่มุม สิ่งทั้งหมดชะลอการรวบรวมข้อมูลเมื่อพยายามเรียกใช้โมเดลการผลิตรถยนต์ที่มีมากกว่า 100,000 รูปหลายเหลี่ยมเพื่อแบ่งย่อย ณ จุดนี้มันไม่สามารถทำการแบ่งย่อยได้ 2 หรือ 3 ระดับโดยไม่ทำให้การรวบรวมข้อมูลช้าลง เพียงแค่เขาเขียนโค้ดที่เหมาะอย่างยิ่งสำหรับขนาดอินพุตที่เล็กอย่างไม่สมจริงที่ไม่ได้ทำ

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